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Abstract 


Virtual  Battle  Experiments  (VBE)  provide  a  simulation  environment  for  the  testing  of 
algorithms  and  operating  procedures.  When  multiple  platforms  are  included  in  the 
simulation,  communication  between  platforms  can  also  be  investigated.  For  example, 
when  certain  data  and  information  are  shared  between  platforms,  the  result  may  be  the 
more  efficient  completion  of  the  simulated  mission.  In  a  naval  setting,  such 
information  may  include  contact  data  within  the  area  of  operation.  However,  for  this 
data  sharing  to  take  place,  the  virtual  platforms  need  to  reach  an  agreement  on  the  data 
structure  and  content.  Research  under  the  auspices  of  The  Technical  Cooperation 
Program,  Maritime  Systems  Group,  Technical  Panel  -  One,  is  investigating  the  use  of 
the  Land  Command  and  Control  Information  Exchange  Data  Model  (LC2IEDM)  for 
the  sharing  of  data  between  virtual  platforms.  This  investigation  details  the  data 
storage  within  LC2IEDM  during  VBE-Bravo,  conducted  in  April  2003.  For  the 
experiment,  the  data  stored  within  LC2IEDM  includes  initial  information  on  the 
coalition  forces,  information  on  enemy  forces,  and  discovered  contacts. 


Resume 


Les  experiences  de  combat  virtuel  (VBE)  constituent  des  environnements  de 
simulation  pour  la  mise  a  fessai  d'algorithmes  et  de  procedures  operationnelles. 
Lorsque  plusieurs  plates-formes  font  partie  d'une  simulation,  il  est  aussi  possible 
d'etudier  les  communications  entre  plates-formes.  Par  exemple,  lorsqu'il  y  a  partage  de 
certaines  donnees  et  de  certains  renseignements  entre  plates-formes,  cela  peut  mener  a 
une  execution  plus  efficiente  de  la  mission  simulee.  Dans  un  milieu  naval, 
f  information  echangee  peut  comprendre  des  donnees  sur  les  contacts  dans  la  zone 
d'operations.  Toutefois,  pour  qu'il  y  ait  partage  des  donnees,  il  doit  y  avoir  entente 
entre  les  plates-formes  virtuelles  au  sujet  de  la  structure  et  du  contenu  des  donnees. 
Des  recherches  menees  sous  les  auspices  du  Comite  technique  1  du  Groupe  d'analyse 
des  systemes  de  marine  du  Programme  de  cooperation  technique  (TP-1  MAR  TTCP) 
portent  sur  futilisation  du  modele  de  donnees  d'echange  d'information  de 
commandement  et  de  controle  (Terre)  (LC2IEDM)  en  vue  du  partage  de  donnees  entre 
plates-formes  virtuelles.  La  presente  etude  decrit  en  detail  le  stockage  des  donnees 
dans  le  LC2IEDM  durant  la  VBE  Bravo,  menee  en  avril  2003.  Aux  fins  de 
f experience,  les  donnees  stockees  dans  le  LC2IEDM  comprenaient  finformation 
initiale  sur  les  forces  de  coalition,  finformation  sur  les  forces  ennemies  et  les  contacts 
detectes. 
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Executive  summary 


Introduction 

Virtual  Battle  Experiments  (VBEs)  are  being  utilized  as  a  mechanism  to  investigate  a 
variety  of  topic  areas  important  to  the  navy.  The  virtual  environment  provides  a  cost 
effective  mechanism  for  testing  algorithms  (e.g.,  target  motion  analysis)  and  operating 
procedures.  Such  an  environment  is  also  well  suited  to  investigate  the  sharing  of  data 
and  information  between  the  virtual  platforms. 

In  this  investigation,  the  data  sharing  between  virtual  platforms  utilizes  a  central  data 
structure.  The  structure,  which  is  the  Land  Command  and  Control  Information 
Exchange  Data  Model  (LC2IEDM),  is  an  international  army-based  effort  that  has 
developed  from  the  Army  Tactical  Command  and  Control  System  (ATCCIS) 
programme  which  originated  in  the  1980s.  LC2IEDM  provides  an  extensive  set  of 
attributes  and  rules  for  sharing  planning  and  operational  data. 

Such  sharing  is  important  within  a  coalition  mode  of  operation.  Sensors  on  remote 
platforms  may  be  used  to  collect  data  within  the  sensors  field  of  reach.  By  sharing  the 
collected  data  among  the  coalition  platforms,  the  effective  area  of  reach  of  any  one 
platform  is  expanded.  The  LC2IEDM  may  be  used  as  the  common  structure  through 
which  data  is  exchanged  between  these  platforms. 

This  report  details  the  use  of  LC2IEDM  in  a  virtual  battle  experiment.  The 
experiment,  conducted  under  the  auspices  of  The  Technical  Cooperation  Program, 
considers  the  sharing  of  information  between  a  submarine  and  two  surface  ships. 
Although  full  two-way  data  communications  was  not  available  during  the  VBE,  the 
report  details  the  one-way  data  placement  into  the  LC2IEDM  during  the  VBE. 


Principal  Results 

This  investigation  provides  detailed  documentation  on  the  use  of  the  LC2IEDM  within 
a  naval  virtual  battle  experiment.  The  report  details  the  data  placement  within 
LC2IEDM  and  highlights  the  types  of  data  that  would  be  important  for  sharing  in  a 
networked  coalition  task  group. 


Significance  of  Results 

The  LC2IEDM  is  being  promoted  as  a  possible  solution  to  the  network-based  sharing 
of  data.  Although  LC2IEDM  has  its  origin  in  the  army,  the  system  is  being  considered 
for  joint  operations.  This  report  provides  a  preliminary  link  between  a  naval  tracking 
operation  within  a  virtual  simulation  and  the  LC2IEDM.  This  link  is  important 
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because  it  provides  the  army-based  LC2IEDM  community  with  a  naval  perspective  on 
the  components  of  the  model  that  may  be  used  in  a  naval  operation.  As  well,  the  naval 
community  is  provided  with  a  template  for  the  data  sharing  that  is  possible  using  the 
LC2IEDM.  Finally,  the  naval  research  community  benefits  from  an  understanding  of 
LC2IEDM  structures  and  how  joint  operations  may  use  such  a  structure  for  the  data 
sharing  requirements  of  a  networked  military. 

The  work  presented  here  is  also  important  for  those  considering  the  use  of  the 
LC2IEDM  in  future  research  and  development.  The  investigation  supports  national 
efforts,  such  as  the  Networked  Underwater  Warfare  (NUW)  Technology 
Demonstration  Project  currently  underway  at  Defence  R&D  Canada  -  Atlantic.  NUW 
intends  to  use  a  virtual  environment  in  algorithm  and  communication  tests  before  sea 
trials.  This  work  provides  background  information  on  how  LC2IEDM  might  fit  into 
such  tests. 


Future  Plans 

There  are  many  potential  avenues  for  future  investigation.  The  extensibility  of  the 
LC2IEDM  for  specific  naval  applications  needs  to  be  explored.  This  activity  will 
support  those  navy-specific  data  types  that  could  be  useful  in  a  networked 
environment.  Such  an  investigation  would  contribute  to  the  Networked  Underwater 
Warfare  Technology  Demonstration  Project  currently  underway  at  Defence  R&D 
Canada  -  Atlantic  and  the  TTCP  efforts  in  Virtual  Battle  Experiments. 

Part  of  the  extensibility  testing  also  needs  to  consider  the  replication  between  instances 
of  the  LC2IEDM.  This  type  of  investigation  could  involve  a  collaborative  effort 
between  DRDC  Atlantic  and  DRDC  Valcartier.  Such  collaboration  would  establish 
positive  linkages  between  the  army  and  navy  areas  of  research. 


Isenor,  Anthony  W.  and  Frederick  G.  Burkley.  2004.  The  Use  of  the  Land  Command 
and  Control  Information  Exchange  Data  Model  in  Virtual  Battle  Experiment  -  Bravo, 
DRDC  Atlantic  TM  2004-002,  Defence  R&D  Canada  -  Atlantic. 
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Sommaire 


Introduction 

Les  experiences  de  combat  virtuel  (VBE)  servent  a  Tetude  de  toute  une  gamme  de 
questions  importantes  pour  la  Marine.  L'environnement  virtuel  constitue  une  solution 
rentable  de  mise  a  Fessai  d'algorithmes  (p.  ex.  Fanalyse  des  mouvements  des  cibles)  et 
de  procedures  operationnelles.  Un  tel  environnement  convient  bien  a  Fetude  du  partage 
de  donnees  et  d'information  entre  plates-formes  virtuelles. 

Dans  la  presente  etude,  des  donnees  presentees  scion  une  structure  commune  sont 
partagees  entre  plates-formes  virtuelles.  Cette  structure,  le  modele  de  donnees 
d'echange  d'information  de  commandement  et  de  controle  (Terre)  (LC2IEDM),  est  le 
fruit  d'un  effort  militaire  international  deploye  dans  le  cadre  du  programme  du  systeme 
tactique  d'information  de  commandement  et  de  controle  de  Farmee  de  terre  (ATCCIS), 
lance  dans  les  annees  1980.  Le  LC2IEDM  comporte  une  serie  exhaustive  de  regies  et 
d'attributs  pour  le  partage  de  donnees  operationnelles  et  de  planification. 

Un  tel  partage  joue  un  role  important  dans  le  mode  de  fonctionnement  en  coalition. 

Des  capteurs  poses  sur  des  plates-formes  eloignees  peuvent  servir  a  la  collecte  de 
donnees  dans  la  zone  de  portee  des  capteurs.  Grace  au  partage  des  donnees  recueillies 
par  les  plates-formes  de  coalition,  la  zone  de  portee  effective  de  n'importe  quelle  plate- 
forme  est  elargie.  Le  LC2IEDM  peut  servir  de  structure  commune  pour  Fechange  de 
donnees  entre  plates-formes. 

Le  present  rapport  decrit  en  detail  Futilisation  du  LC2IEDM  dans  une  VBE. 
L'experience,  menee  sous  les  auspices  du  Programme  de  cooperation  technique 
(TTCP),  portait  sur  le  partage  d'information  entre  un  sous-marin  et  deux  navires  de 
surface.  Meme  si  la  transmission  de  donnees  entierement  bidirectionnelle  n'etait  pas 
disponible  durant  la  VBE,  le  rapport  decrit  en  detail  le  stockage  unidirectionnel  de 
donnees  dans  le  LC2IEDM  durant  la  VBE. 


Resultats 

La  presente  etude  comporte  une  documentation  detaillee  sur  Futilisation  du  LC2IEDM 
dans  une  experience  de  combat  virtuel  naval.  Le  rapport  decrit  en  detail  le  stockage  des 
donnees  dans  le  LC2IEDM  et  fait  ressortir  les  types  de  donnees  qu'il  serait  important 
de  partager  dans  un  groupe  operationnel  de  coalition  en  reseau. 
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Portee 


On  fait  la  promotion  du  LC2IEDM  comme  solution  possible  en  vue  du  partage  de 
donnees  en  reseau.  Meme  si  le  LC2IEDM  provient  a  forigine  de  FArmee  de  terre,  le 
modele  est  considere  pour  des  operations  interarmees.  Le  present  rapport  etablit  un  lien 
preliminaire  entre  une  operation  de  poursuite  navale  dans  une  simulation  virtuelle  et  le 
LC2IEDM.  II  est  important  d'etablir  un  tel  lien  parce  que  cela  donne  aux  utilisateurs  du 
LC2IEDM  de  FArmee  de  terre  une  perspective  navale  sur  les  composants  du  modele 
susceptibles  d'etre  utilises  dans  une  operation  navale.  En  outre,  un  modele  est  foumi  au 
milieu  naval  pour  le  partage  des  donnees  qu'il  est  possible  de  realiser  grace  au 
LC2IEDM.  Enfin,  le  milieu  de  la  recherche  navale  beneficie  d'une  comprehension  des 
structures  du  LC2IEDM  et  de  la  fagon  dont  les  operations  interarmees  pourraient 
utiliser  un  tel  systeme  pour  les  besoins  de  partage  de  donnees  des  militaires  en  reseau. 

Le  travail  decrit  aux  presentes  est  egalement  important  pour  ceux  qui  envisagent  la 
possibilite  de  se  servir  du  LC2IEDM  dans  de  futurs  travaux  de  recherche  et 
developpement.  L'etude  vient  a  Fappui  des  efforts  nationaux,  comme  le  projet  de 
demonstration  de  technologic  de  guerre  sous-marine  en  reseau  (NUW),  en  cours  a  R  & 
D  pour  la  defense  Canada  -  Atlantique.  Ce  projet  vise  le  recours  a  un  environnement 
virtuel  durant  les  essais  des  algorithmes  et  des  communications  avant  les  essais  en  mer. 
Le  present  travail  fournit  des  renseignements  generaux  sur  la  fagon  dont  le  LC2IEDM 
pourrait  etre  integre  a  ces  essais. 


Recherches  futures 

II  y  a  de  nombreuses  possibilites  de  recherches  futures.  La  possibilite  d'etendre  le 
LC2IEDM  a  des  applications  navales  precises  doit  etre  exploree.  Cette  activite  prendra 
en  charge  les  types  de  donnees  propres  a  la  Marine  qui  pourraient  se  reveler  utiles  dans 
un  environnement  en  reseau.  Une  telle  etude  contribuerait  au  projet  de  demonstration 
de  technologic  de  NUW,  en  cours  a  R  &  D  pour  la  defense  Canada  -  Atlantique,  et  aux 
efforts  sous  les  auspices  du  TTCP  dans  le  cadre  des  VBE. 

Une  partie  des  essais  sur  les  possibilites  d'extension  doit  egalement  tenir  compte  des 
cas  de  dedoublement  dans  le  LC2IEDM.  Ce  type  d'etude  pourrait  donner  lieu  a  un 
effort  de  collaboration  entre  RDDC  Atlantique  et  RDDC  Valcartier.  Une  telle 
collaboration  permettrait  d'etablir  des  rapports  positifs  entre  les  secteurs  de  recherche 
de  FArmee  de  terre  et  de  la  Marine. 
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1.  Introduction 


Military  research  has  traditionally  focused  on  the  three  main  branches  of  the  military 
establishment  -  army,  air  force  and  navy.  Each  branch  has  conducted  research  and 
development  in  subject  areas  that  often  combine  the  disciplines  of  physics,  chemistry 
and  mathematics  to  solve  problems  related  to  topics  such  as  platform  performance, 
combat  or  processing  systems,  and  the  sensing  or  detection  of  threats  in  an  area  of 
interest. 

The  early  research  efforts  were  labour  intensive.  As  an  example,  consider  early 
Canadian  naval  research,  which  concentrated  efforts  on  ship  degaussing  [1]  during 
World  War  II.  Calculations  were  typically  done  with  paper,  pencil  and  a  slide  rule. 

The  rise  in  computing  power  greatly  impacted  this  type  of  research.  Algorithms  were 
coded  in  software,  and  the  computers  became  our  number  processing  machines. 

The  most  obvious  direct  implication  of  computing  power  was  in  numeric  processing. 
However,  the  influence  of  computers  now  encompasses  all  realms  of  research. 
Computers  not  only  perform  the  mundane  numeric  processing  but  also  model  all 
aspects  of  the  research  from  sensor  development  to  large-scale  platform  performance. 
Computers  have  become  ubiquitous  throughout  the  research  process. 

As  part  of  this  expansion,  computers  are  now  being  used  to  model  entire  operations.  In 
such  cases,  computers  are  used  for  more  than  algorithm  processing.  In  these  cases,  the 
computer  provides  a  simulation  of  a  complete  environment.  Such  environments  are 
often  referred  to  as  virtual  environments. 

In  naval  research,  organisations  have  begun  utilizing  virtual  environments. 

Researchers  are  using  virtual  ships  to  study  a  variety  of  issues  involving  algorithm 
development  and  communications.  When  researchers  employ  multiple  virtual  ships, 
platform  communication  issues  may  be  investigated. 

Of  particular  interest  in  many  such  investigations  is  the  possible  performance 
implications  associated  with  multi-ship  communications.  In  a  multi-ship  environment, 
the  sharing  of  data  and  information  between  platforms  may  have  implications  on 
mission  success  or  the  speed  to  mission  completion.  Such  network  sharing  of 
information  is  commonly  referred  to  as  network  enabled  capabilities  (NEC)  [2].  In  the 
United  States  (US),  a  doctrine  is  developing  around  the  use  of  the  network.  This 
doctrine  is  commonly  referred  to  as  net-centric  warfare  (NCW)  [3]. 

In  a  virtual  environment,  the  complicated  issue  of  network  sharing  of  data  and 
information  can  be  researched  in  a  very  cost-effective  way.  In  the  virtual  environment, 
the  researcher  has  complete  control  over  all  conditions.  For  example,  there  is  no 
downtime  due  to  poor  weather,  as  is  sometimes  the  case  in  sea  trials.  Researchers  can 
also  easily  task  a  component  of  the  virtual  environment.  A  virtual  ship  can  easily  be 
assigned  a  task  within  a  certain  operational  area. 
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Numerous  countries  are  now  using  virtual  environments  as  a  research  tool.  For 
example,  Australia  (AS)  has  made  considerable  progress  in  modelling  virtual 
submarines  [4].  Through  The  Technical  Cooperation  Program  (TTCP)  Maritime 
Systems  Group  (MAR)  Technical  Panel  -  1  (TP-1),  much  of  this  effort  has  been  made 
available  to  member  countries,  including  Canada  (CA)  and  the  US.  New  Zealand  (NZ) 
has  also  conducted  a  virtual  experiment,  and  the  United  Kingdom  (UK)  is  presently 
planning  an  experiment. 

In  Canada,  virtual  experiments  are  now  being  planned  and  conducted  at  DRDC 
Atlantic  [5].  These  experiments  are  designed  to  explore  the  implications  of  additional 
information  that  may  be  made  available  in  a  networked  environment  [6,  7].  Although 
in  the  preliminary  stages,  these  experiments  use  much  of  the  infrastructure  made 
available  through  TTCP  relationships. 

Internationally  through  TTCP,  considerable  effort  has  been  directed  towards  virtual 
experiments  that  integrate  and  assess  new  algorithms  for  such  tasks  as  target  motion 
analysis  and  data  fusion  [8,  9].  Researchers  develop  new  or  improved  algorithms, 
make  these  algorithms  available  to  an  operator  in  the  virtual  environment,  and  run  a 
planned  scenario  that  utilizes  the  new  algorithm.  Such  experiments  have  typically 
taken  the  form  of  a  virtual  situation  involving  an  encounter  with  enemy  forces,  or 
loosely  a  virtual  battle.  Thus,  the  investigations  have  been  labelled  Virtual  Battle 
Experiments  (VBEs). 

VBEs  involving  more  than  one  virtual  coalition  platform  have  the  potential  to 
investigate  the  sharing  of  data  and  information  within  the  coalition  force.  In  this  case, 
the  VBE  can  examine  how  the  sharing  of  data  and  information  can  enhance  or 
influence  the  actions  of  the  coalition  force.  For  example,  TTCP  VBEs  are  examining 
enhancements  to  picture  compilation  when  platforms  share  information.  As  well, 
efforts  are  underway  to  perform  the  data  analysis  necessary  to  quantify  any  picture 
compilation  benefits  [10]. 

An  important  point  in  any  investigation  examining  information  sharing  is  the  type  of 
information  being  shared.  In  the  international  VBEs,  one  component  of  the 
experiment  is  examining  the  data  storage  capabilities  of  the  Land  Command  and 
Control  Information  Exchange  Data  Model  (LC2IEDM).  This  data  model  is  army 
based,  and  is  now  part  of  the  NATO  corporate  data  model  [11]. 

The  LC2IEDM  is  well  documented  in  terms  of  system-level  documentation  [12,  13]. 
Recent  investigations  have  also  examined  the  LC2IEDM  from  the  perspective  of  navy 
tactical  data  storage  of  contact  data  [14].  In  the  VBEs,  the  LC2IEDM  is  at  present 
being  used  as  a  central  storage  location  for  information.  In  future  VBEs,  researchers 
hope  to  investigate  the  flow  of  information  through  the  LC2IEDM  between  the  many 
coalition  platforms  within  the  virtual  environment. 

It  should  be  noted  that  the  LC2IEDM  was  initially  known  as  the  Generic  Hub  (GH) 
data  model.  Many  organisations  still  refer  to  the  model  as  the  Generic  Hub.  This 
name  originated  from  the  concept  of  having  a  generic  data  model  for  multipurpose 
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operations  that  would  form  a  hub  for  new  system  development  [12].  The  name  was 
changed  in  1999  to  the  LC2IEDM  to  better  describe  its  function. 

Recent  efforts  to  address  joint  operations  have  further  evolved  the  name  to  Command 
and  Control  Information  Exchange  Data  Model  (C2IEDM).  However,  the  data  model 
firmly  has  its  origin  in  the  army.  Such  data- space  expansion  into  joint  operations  is 
not  without  controversy.  Some  suggest  the  data  model  is  presently  too  large  and 
complex,  and  should  not  be  expanded  toward  joint  operations  [15]. 

Although  the  core  functions  of  Generic  Hub,  LC2IEDM  and  C2IEDM  are  similar,  they 
are  nevertheless  different  data  models.  In  the  following  report,  we  have  used  the 
LC2IEDM.  We  shall  refer  to  both  the  data  model  and  the  database  as  LC2IEDM. 


1.1  Outline  of  the  Report 

This  document  presents  an  investigation  of  data  placement  in  the  LC2IEDM  in  support 
of  a  VBE.  The  VBE  data  placement  in  the  LC2IEDM  database  will  illustrate  various 
points.  First,  it  will  provide  the  reader  with  an  understanding  of  the  relationships 
within  the  model.  The  LC2IEDM  has  an  extensive  table  and  relationship  structure  and 
may  appear  overly  complicated  to  many  readers.  However,  the  report  will  attempt  to 
minimize  the  complexity  by  stepping  through  the  data  insertion  into  the  LC2IEDM  in  a 
progressive  manner,  documenting  the  actual  data  insertion  and  why  it  is  required  for 
the  LC2IEDM  structure.  Hopefully,  this  will  reduce  the  complications  for  the  reader. 

The  second  point  to  consider  is  the  documentation  associated  with  the  model.  Any 
insertion  of  data  into  a  previously  unknown  data  model  will  test  the  accompanying 
documentation.  The  LC2IEDM  has  extensive  and  often  complicated  relationships. 

This  means  the  documentation  must  be  capable  of  presenting  these  complications  to  a 
generally  uninformed  reader. 

Considerable  documentation  already  exists  for  the  LC2IEDM  [12,  13,  16,  17,  18,  19]. 
This  report  is  somewhat  different  from  the  other  LC2IEDM  documentation  in  that  this 
report  details  the  insertion  of  data  particular  to  the  VBE,  into  the  LC2IEDM.  The 
report  will  explain  only  those  tables  used  during  the  insertion.  In  this  regard,  this 
report  is  application  specific,  and  is  not  general  documentation  for  the  LC2IEDM. 


1 .2  Syntax  of  the  Report 

Throughout  this  report,  considerable  nomenclature  will  be  used  to  describe  the 
structure  of  the  data  model.  The  LC2IEDM  database  tables  will  be  denoted  in 
uppercase  characters  (e.g.,  OBJ  ITEM).  The  LC2IEDM  table  column  names  will  also 
be  uppercase.  Note  that  columns  will  be  associated  with  tables,  and  thus  the  physical 
implementation  of  the  data  model.  The  logical  model  will  be  described  using  entities 
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and  attributes  in  place  of  the  physical  model  tables  and  columns.  The  logical  model 
entity  and  attribute  names  will  be  identified  in  italic  font,  with  a  single  dash  separating 
the  words  that  comprise  the  name  (e.g.,  object-item).  Although  not  exactly  correct,  we 
will  refer  to  table  names  using  the  logical  model  names.  We  hope  this  will  improve 
the  readability  of  the  report. 

The  LC2IEDM  system  will  also  be  described  using  both  the  data  model  and  the 
database.  The  two  (data  model  and  database)  are  different,  as  you  cannot  place  data 
into  a  data  model.  The  data  model  is  the  blueprint  for  the  construction  of  the  database. 
However,  for  the  purpose  of  this  report  both  the  data  model  and  database  will  be 
referred  to  as  LC2IEDM. 

Finally,  we  will  use  the  extensible  Markup  Language  (XML)  to  input  data  into  the 
LC2IEDM.  In  this  report,  XML  tags  will  be  denoted  in  the  text  including  the  angle 
brackets  <>.  This  should  uniquely  identify  an  XML  tag  name  from  a  database  column 
name  in  those  cases  where  the  two  are  the  same.  The  content  of  the  XML  tag  will  be 
identified  using  double  ‘‘quotes”  with  the  actual  content  in  Arial  font  (e.g.,  “5”). 

The  XML  will  be  used  to  identify  the  LC2IEDM  tables  and  records.  An  XML  tag 
containing  the  suffix  “_TBL>”  will  be  used  to  indicate  the  table  being  loaded.  For 
example,  the  tag  <REF_TBL>  identifies  the  REF  table.  An  individual  record  in  the 
database  table  will  be  identified  with  an  XML  tag  containing  only  the  table  name.  For 
example,  the  tag  <REF>  indicates  the  start  of  a  record  to  be  loaded  to  the  REF  table. 
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2.  System Components 


There  are  many  software  components  being  utilized  in  this  investigation.  The 
databases  form  only  a  part  of  the  system.  The  following  provides  a  brief  introduction 
to  the  main  software  components.  The  introduction  is  not  intended  to  convey  the 
details  of  using  or  implementing  these  components.  Rather,  it  is  intended  to  provide 
an  overview  of  the  important  components  for  this  investigation. 


2.1  ERwin™ 

ERwin™  is  an  entity-relationship  modelling  software  package  developed  by  Computer 
Associates  [20].  The  LC2IEDM  is  available  in  the  ERwin™  format,  version  3.5.2. 

The  ERwin™  software  used  during  this  investigation  was  version  4.1.2522. 

ERwin™  has  been  used  for  the  full  LC2IEDM  development  cycle.  The  software 
provides  a  graphical  user  interface  to  allow  the  user  point-and-click  model  design 
capabilities.  Entity  and  relationship  properties  are  quickly  accessible.  As  well, 
ERwin^^  provides  a  domain  dictionary  for  the  creation  and  management  of  entities 
and  relationships. 

ERwin™  also  provides  the  database  design  generation.  This  means  that  ERwin™  can 
generate  the  necessary  Structured  Query  Language  (SQL)  commands  to  create  the 
actual  database  from  the  model. 

There  are  two  important  features  that  make  the  data  modelling  software  important  for 
this  investigation.  First,  the  software  allows  the  visualization  of  the  data  model.  This 
is  particularly  important  when  attempting  to  understand  the  relationships  between 
entities.  As  well,  the  user  may  define  the  level  of  complexity  in  the  visualization.  This 
means  that  areas  of  the  data  model  may  be  isolated  and  visualized  without  considering 
the  entire  model.  The  LC2IEDM  data  model  diagrams  presented  in  this  report  are 
from  the  ERwin^^  software. 

Second,  ERwin™  allows  quick  search  and  selection  of  entities,  attributes,  and 
relationships.  This  can  save  considerable  time  as  compared  to  searching  multiple 
volumes  of  documentation  to  identify  all  the  characteristics  of  a  particular  entity, 
attribute  or  relationship. 
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2.2  Land  Command  and  Control  Information  Exchange 
Data  Model 

LC2IEDM  data  model  defines  standard  elements  of  information.  These  elements  are 
considered  the  basis  for  interoperability  between  those  automated  NATO  national 
Command  and  Control  Information  Systems  (C2ISs)  that  accommodate  the  model's 
information  structure  [12]. 

The  NATO  requirement  was  to  define  only  the  information  that  is  to  be  exchanged, 
rather  than  model  all  of  the  information  that  would  normally  be  required  by  a  national 
system.  Information  exchange  requirements  will  change  over  time,  and  for  that  reason 
there  was  a  need  to  design  a  flexible  generic  model  that  could  adapt  over  time  to 
changing  information  needs  as  well  as  serve  as  a  basis  or  hub  for  new  national 
systems.  For  these  reasons  the  data  model  was  originally  known  as  the  Generic  Hub 
(GH)  Data  Model. 

The  LC2IEDM  data  model  can  be  broken  down  into  three  components: 

•  A  Conceptual  Data  Model  that  represents  the  high  level  view  of  the 
information  to  enable  senior  staff  to  verify  the  scope  of  the  information 
structure. 

•  The  Logical  Data  Model  is  the  core  component  that  represents  all  of  the 
information  and  is  based  upon  breaking  down  the  high  level  concepts  into 
information  that  is  regularly  used.  For  example  a  submarine  is  a  military 
maritime  vessel  that  is  a  piece  of  equipment  that  is  a  piece  of  materiel.  This 
breakdown  follows  human  reasoning  patterns.  The  model  specifies  the  way 
information  is  structured  using  entity-attribute-relationship  diagrams  and 
supporting  documentation. 

•  A  Physical  Data  Model  that  defines  the  structure  of  the  database,  which 
currently  consists  of  196  tables  and  about  1200  fields  within  an  Oracle 
database. 

Both  the  physical  and  logical  models  are  available  in  ERwin™  diagrams. 


2.3  Oracle 

Oracle™  [21]  is  a  company  specializing  in  information  management  software.  The 
Oracle™  product  line  includes  specialized  software  for  database  management, 
development  tools,  application  server  tools,  collaboration  suites  and  data  warehousing 
tools.  Oracle™  is  reported  to  be  the  second  largest  software  company  in  the  world, 
with  annual  revenues  of  about  10  billion  dollars  [22]  and  a  database  market  share  of 
39.4%  [23]. 
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The  Oracle™  Company  markets  the  Oracle™  database  (hereafter,  “Oracle”  will  refer 
to  the  database).  The  Lite  version  of  the  database  is  available  for  free  download. 
Personal  Oracle9i  Release  9.2.0. 1.0  (for  the  Win2000  PC)  comes  packaged  with 
numerous  application  tools  including  the  command  line  interface  SQL  Plus.  The 
Oracle  database  is  used  in  this  LC2IEDM  implementation. 

SQL  Plus  provides  command  line  functionality  to  standard  SQL  and  extended 
functionality  particular  to  Oracle.  The  software  may  be  executed  either  via  the 
windows  menu  system  or  from  a  DOS  command  window.  Some  useful  SQL  Plus 
commands  are  listed  in  Table  1.  Documentation  for  SQL  Plus  is  also  available  [24]. 


Table  1.  Some  commands  for  the  SQL  Plus  command  line  interface  to  an  Oracle  database. 


COMMAND 

FUNCTION 

help  index 

Obtain  help  on  SQL  Plus  commands. 

desc 

List  column  definitions  for  a  table. 

quit 

Quit  the  command  line  interface. 

@ 

Allows  execution  of  script  file. 

2.4  Operational  Context  Exchange  Service 

The  Operational  Context  Exchange  Service  (OCXS)  is  being  developed  by  the  Naval 
Undersea  Warfare  Center  (NUWC)  [25]  in  the  US  to  provide  a  coalition  data  server 
and  supporting  services  based  upon  the  NATO-developed  LC2IEDM.  OCXS  is  a  Java 
software  suite  designed  to  act  as  a  bridge  between  the  LC2IEDM  and  outside 
applications. 

The  OCXS  suite  utilizes  logical  and  physical  XML  tag  sets  based  on  the  logical  and 
physical  name  sets  used  in  the  ERwin™  LC2IEDM  model.  The  logical  name  set  used 
by  OCXS  duplicates  the  naming  convention  used  in  the  LC2IEDM  logical  model.  The 
physical  name  set  duplicates  the  naming  convention  used  in  the  LC2IEDM  physical 
model.  Note  that  the  physical  model  corresponds  to  the  tables  and  field  names  used  in 
the  actual  Oracle  implementation  of  the  LC2IEDM. 

Data  may  be  input  to  the  LC2IEDM  using  OCXS  and  the  physical  XML  name  set.  If 
data  exist  using  the  logical  name  set,  a  converter  is  provided  to  transform  the  logical  to 
physical  name  sets.  This  transformation  is  performed  using  extensible  Stylesheet 
Language  Transformations  (XSLT).  A  brief  introduction  to  XSLT  is  presented  in  [26]. 

OCXS  inputs  the  data  to  the  LC2IEDM  using  the  physical  XML  name  set.  All 
relationships  within  the  LC2IEDM  are  dealt  with  implicitly  from  the  data  file.  The 
initial  OCXS  implementation  did  not  deal  with  any  LC2IEDM  relationships.  This 
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means  that  the  input  XML  document  must  load  the  LC2IEDM  tables  without  violating 
any  formal  relationships  in  the  LC2IEDM. 

Note  that  subsequent  OCXS  revisions  provide  an  object  oriented  message  interface  to 
LC2IEDM.  These  object-based  messages  generate  appropriate  XML  documents  for 
input  to  LC2IEDM. 

OCXS  also  deals  with  output  from  the  LC2IEDM.  OCXS  can  request  information 
from  the  LC2IEDM,  with  the  information  being  made  available  to  the  user  as  a 
physical  XML  tag  set.  If  desired,  this  physical  tag  set  can  be  converted  to  a  logical  tag 
set  via  an  XSLT  transform.  The  OCXS  output  mechanism  was  not  utilized  during  this 
investigation. 

The  OCXS  Service  employs  a  three-tier  architecture  shown  in  Figure  1,  consisting  of 
the  following  software  components: 

•  Communications  (Comms)  Library  -  This  is  the  client  tier  Application 
Programming  Interface.  The  Comms  Library  allows  clients  (producers  and 
consumers,  described  below)  to  send  messages  to  and  retrieve  them  from  the 
Server  Tier  of  the  OCXS  Service. 

•  Application  Server  -  The  server  tier  communicates  with  the  Comms  Library 
and  the  backend  LC2IEDM  database.  This  tier  presently  consists  of  two  Java 
Servlets;  one  Servlet  handles  producer  messages  (Producer  Servlet)  and  the 
other  handles  consumer  messages  (Consumer  Servlet). 

•  Database  -  The  LC2IEDM  Version  5  database. 


Figure  1.  OCXS  Service  architecture  consists  of  three  tiers:  the  Communication  library,  the 

application  server  and  the  database. 


The  current  version  of  the  OCXS  software  library  delivered  by  NUWC  now  supports 
the  following  functionality: 

•  An  Application  Server  that  populates  LC2IEDM  via  the  ingestion  of  XML 
messages.  This  is  a  generic  service  that  will  write  any  conformant  XML 


8 


DRDC  Atlantic  TM  2004-002 


message  to  the  database.  A  conformant  XML  message  is  a  message  that  uses 
the  LC2IEDM  physical  name  set  and  adheres  to  the  formal  relationships 
mandated  by  LC2IEDM  (i.e.,  matches  the  physical  database  schema  and 
honors  referential  integrity  constraints). 

•  A  client  tier  Application  Programming  Interface  (API)  supporting  XML 
message  transmission. 

•  A  set  of  objects  that  facilitate  XML  message  generation  and  ingestion. 

Support  currently  exists  for  unit  position  report  and  track  messages.  For 
example,  a  unit  position  report  object  knows  how  to  generate  the  XML 
message  corresponding  to  a  unit  position  report  (a  self  report  of  latitude  / 
longitude  position).  This  facilitates  the  use  of  the  LC2IEDM  data  model 
without  a  rigorous  understanding  of  all  of  the  model’s  formal  relationships. 

•  Support  for  high-level  unit  position  and  track  attribute  requests.  This  attribute 
message  gives  clients  high-level  summary  information  about  platforms  within 
LC2IEDM.  This  message  allows  clients  to  determine  which  platforms  are  of 
sufficient  interest  to  warrant  further  investigation. 

•  Support  for  detailed  unit  position  and  track  requests.  This  message  gives 
clients  the  latest  attribute,  positional  and  kinematic  information  about 
platforms  within  LC2IEDM.  Attribute  information  such  as  platform  threat, 
positional  information  such  as  latitude  /  longitude,  kinematic  information  such 
as  course  and  speed. 


2.4.1  OCXS  Service  Architecture  in  VBE-B 

For  VBE-B,  all  three  components  of  the  OCXS  Service  were  deployed  on  a  single 
system;  a  Gateway  laptop  with  a  2  Gigahertz  Pentium  4  processor,  512  Megabytes  of 
RAM  and  a  single  30  Gigabyte  IDE  disk  drive  (5400  RPM).  The  OCXS  Gateway 
Federate  was  also  deployed  on  that  system.  This  was  done  for  ease  of  configuration. 

This  simplified  architecture  removed  two  sources  of  delay  for  OCXS  messages.  There 
was  no  external  network  delay  from  the  Comms  Library  to  the  Application  Server  and 
no  external  network  delay  from  the  Application  Server  to  the  database.  Conversely,  all 
processes  shared  the  same  CPU. 


2.4.2  Producer  Message  Processing 

This  Section  details  the  processing  stages  of  producer  messages.  There  are  two  types 
of  producer  messages:  Unit  Position  Reports  and  Solution  Reports. 
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Unit  Position  Reports  detail  the  present  position  of  the  reporting  object.  This  is  a 
self-report  on  the  location  of  the  reporting  platform. 

The  Solution  Report  deals  with  the  information  on  a  contact.  The  processing  pipeline 
is  the  same  for  each  message  type. 

We  now  detail  the  sequence  of  events  that  occurs  when  a  producer  generates  a 
message  for  the  OCXS  Service.  This  message  (Unit  Position  Report  or  Solution 
Report)  is  created  in  the  client  tier,  passed  to  the  Application  Service  tier,  then  passed 
to  the  database  tier.  The  final  result  is  the  entry  of  the  message  into  the  LC2IEDM 
database. 

As  will  be  seen,  stylesheet  processing  occurs  in  the  client  tier,  SQL  generation  and 
transmission  occurs  in  the  Application  Service  tier,  and  the  database  write  occurs  in 
the  database  tier. 

The  following  processing  occurs  in  the  client  tier: 

•  An  object  (representing  a  producer  message)  is  passed  into  the  Comms 
Library. 

•  An  XML  message  is  generated.  This  message  conforms  to  the  logical  schema 
of  the  LC2IEDM  (Version  5)  data  model. 

•  An  XSLT  stylesheet  is  applied,  transforming  the  message  to  conform  to  the 
physical  schema  of  the  LC2IEDM  (Version  5)  data  model. 

•  The  (transformed)  XML  message  is  transmitted  to  the  Producer  Servlet 
(Application  Server). 

The  following  processing  occurs  in  the  producer  tier: 

•  The  XML  message  is  received  and  parsed  via  a  Simple  API  for  XML  (SAX) 
parser. 

•  Each  element  in  the  message  is  transformed  into  a  SQL  insert  statement.  It  is 
possible  to  achieve  this  in  a  generic  fashion,  since  the  XML  message  conforms 
to  the  physical  schema  of  the  LC2IEDM  (Version  5)  data  model. 

•  Each  SQL  statement  is  submitted  to  the  database  engine  via  Java  Database 
Connectivity  (JDBC). 

The  following  processing  occurs  in  the  database  tier: 

•  The  database  performs  the  inserts.  An  exception  is  thrown  if  necessary.  For 
example,  an  exception  would  result  in  a  load  that  violates  a  relationship  in  the 
database. 


10 


DRDC  Atlantic  TM  2004-002 


This  is  illustrated  in  Figure  2. 


Client  Tier  (Application  Server)  Database  Tier 

Figure  2.  The  OCXS  producer  message  processing  pipeline. 
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3.  Virtual  Battle  Experiment 


A  Virtual  Battle  Experiment  is  a  lab-based  simulation,  where  operators  are  immersed 
in  a  synthetic  environment.  Operators  are  provided  with  a  suite  of  tactical  applications 
that  are  used  to  respond  to  the  evolving  scenario.  The  simulation  environment  is 
common  to  all  VBEs  and  as  such,  allows  the  easy  incorporation  of  national 
applications.  This  allows  individual  countries  the  flexibility  to  conceive,  develop  and 
integrate  applications  important  to  their  national  research  objectives. 

One  focus  of  the  VBE  is  to  provide  an  environment  for  the  testing  of  NEC.  The  virtual 
environment  provides  the  flexibility  to  test  both  the  specific  and  broad  aspects  of  the 
experiment.  In  terms  of  specifics,  a  VBE  may  examine  the  details  of  a  tactical 
application,  in  terms  of  performance  or  applicability  to  situations.  In  a  broad  capacity, 
a  VBE  may  examine  the  picture  compilation,  which  encompasses  the  numerous 
applications  and  complex  interactions  involving  the  operators. 

Within  the  broad  focus  of  NEC,  VBEs  also  provide  an  excellent  opportunity  for  the 
testing  of  information  exchange  requirements.  Typically,  VBE  scenarios  involve 
numerous  platforms  operating  as  a  coalition  group.  In  this  respect,  researching  the 
information  to  be  exchanged  between  the  platforms  is  a  valuable  aspect  of  the 
experiment. 


3.1  Scenario  Description  of  VBE-Bravo 

There  were  numerous  objectives  and  hypothesis  identified  during  the  planning  of 
VBE-B.  In  a  summarized  form,  several  objectives  of  the  experiment  concentrated  on 
the  integration  and  assessment  of  applications  into  the  VBE  infrastructure.  In  VBE 
terminology,  these  applications  are  called  federates.  The  OCXS  gateway  federate  was 
one  of  these  applications  [8]. 

The  scenario  for  VBE-B  outlined  a  coalition  force  involved  in  surveillance  and 
reconnaissance  activities  off  a  foreign  coast  [8].  The  force  included  two  surface 
platforms,  an  unmanned  aerial  vehicle  (UAV)  and  a  submarine  (see  Table  2).  The 
submarine  represented  the  ownship  of  the  VBE  operators.  Two  hostile  frigates^ 
represented  the  red  force.  There  were  also  numerous  fishing  and  merchant  vessels  in 
the  area  of  operation. 


^  The  scenario  description  never  indicated  the  actual  number  of  hostile  frigates.  It  is  unclear  how  two 
hostile  frigates  were  determined  to  be  in  the  scenario.  It  may  have  been  a  direct  result  of  the 
experiment  being  terminated  after  30  minutes  due  to  technical  difficulties  [10]  and  restarted  on  the 
following  day. 
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For  the  experiment,  the  movement  of  all  platforms  except  the  submarine  (named 
Sheean^)  is  completely  scripted.  The  Sheean,  which  is  ownship,  has  an  initial  course, 
speed  and  depth  defined,  but  upon  start-up  of  the  experiment,  the  Commanding  Officer 
is  then  in  charge  of  the  movements  of  the  Sheean. 

It  should  be  noted  that  the  UAV  was  not  visible  to  any  other  platform  in  the  scenario. 
The  UAV  was  in  effect  a  stealth  unit.  The  addition  of  the  UAV  federate  to  the  VBE 
was  effectively  testing  the  integration  aspects  of  the  federate.  Further  developments  by 
New  Zealand  will  enhance  the  federate,  moving  the  UAV  towards  the  full  functionality 
of  a  maritime  patrol  aircraft. 


Table  2.  The  platforms  involved  in  VBE-B. 


PLATFORM 

DESCRIPTION 

FFH1  (HMCS  Halifax) 

(FFH  indicates  Frigate, 
Helicopter) 

A  friendly  Halifax  class  frigate  from  Canada. 

FFH2  (HMNZS  Te  Kaha) 

A  friendly  Halifax  class  frigate  from  New  Zealand. 

Submarine 
(HMAS  Sheean^) 

An  Australian  submarine,  which  is  ownship. 

Unmanned  Aerial  Vehicle 
(UAV) 

A  New  Zealand-based  UAV.  This  was  a  stealth  observer  unit  that  was  not  an  active 
participant  in  VBE-B. 

FFG1  Hostile  Frigate 
(FFG  indicates  Guided 

Missile  Frigate) 

A  hostile  frigate  known  to  be  in  the  area. 

FFG2  Hostile  Frigate 

A  hostile  frigate  known  to  be  in  the  area. 

Merchant  Vessels 

Seven  merchant  ships  were  in  the  area.  The  exact  number  was  not  known  at  the  start 
of  the  experiment. 

Fishing  Vessels 

Two  fishing  vessels  were  in  the  area.  The  exact  number  was  not  known  at  the  start  of 
the  experiment. 

^  In  the  VBE-B  Experimental  Plan,  ownship  was  named  vWaller.  This  was  changed  before  the 
experiment  to  Sheean. 
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4.  VBE-B  Data  Load  to  LC2IEDM 


The  data  load  for  any  VBE  takes  place  in  two  conceptual  parts.  The  first  represents  the 
known  or  initial  state  of  the  scenario.  In  this  part,  all  known  platforms  and 
organisations  are  entered  into  the  LC2IEDM  database. 

The  second  conceptual  part  actually  represents  numerous  loads  of  similar  structure  and 
content.  These  loads  are  the  positioning  information  associated  with  known  platforms, 
and  any  reports  of  newly  detected  platforms.  These  loads  account  for  the  discovery  of 
previously  undetected  platforms  in  the  operational  area. 

In  what  follows,  both  conceptual  parts  of  the  data  load  will  be  explained  in  terms  of  the 
physical  XML  input  for  the  OCXS.  The  various  sections  of  the  input  XML  will  be 
described  in  order  of  occurrence.  The  contiguous  XML  document  may  be  found  in 
Annex  1. 


4.1  Initial  Load  -  Coalition  Data 

The  initial  data  load  contains  the  information  pertinent  to  the  platforms  known  or 
thought  to  be  in  the  area.  Based  on  the  scenario  description  [8],  the  known  platforms 
consist  of  the  coalition  force,  two  hostile  frigates  and  an  assortment  of  fishing  and 
merchant  vessels.  In  some  cases,  the  particular  vessels  are  not  known,  but  the  class  of 
vessel  in  the  area  is  known.  For  example,  it  is  known  that  fishing  vessels  are  in  the 
area,  but  the  exact  location,  number  and  vessel  characteristics  are  not  known. 


4.1.1  Reference  Information 

The  data  load  begins  with  the  placement  of  reference  information  in  the  REF 
(reference)  table  of  LC2IEDM.  The  reference  information  is  shown  in  Figure  3.  The 
reference  is  intended  to  allude  to  the  source  of  the  represented  information  in  the 
LC2IEDM  [12]. 

The  reference-id  (<REF_ID>)  shown  in  Figure  3  is  a  unique  numeric  identifier  for  the 
record.  The  format-code  indicates  the  specific  formatting  of  the  referenced 
information.  For  example,  the  original  information  source  may  have  been  in  the  form 
of  the  NATO  Allied  Data  Publication  -  3  format  (ADatP-3)  version  1 1 .  In  this  case, 
the  format-code  would  indicate  that  the  original  message  was  ADatP-3  version  by 
using  the  code  “AP3V 1 1  ”.  In  the  load  used  for  VBE-B,  the  format  code  of  “NOS” 
indicates  that  the  format  is  not  otherwise  specified  [13]. 
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The  descriptive-text  and  the  source-text  fields  are  unformatted  character  string  fields. 
In  the  VBE-B  load,  these  fields  identify  that  MAR  TP-1  is  conducting  the  VBE  and 
that  OCXS  is  being  used  in  the  data  fill.  The  security-classification  of  the  reference  is 
“NU”  indicating  NATO  unclassified  [13].  The  transmission-type  code  indicates  the 
type  of  incoming  transmission  where  the  information  originated.  The  code 
“EMLMSG”  indicates  that  the  information  originated  in  an  email  message  [13]. 


<?xml  version=" 1 . 0 "  encoding="UTF-8 " ?> 

<GH5Complete  xmlns : dt="urn : schemas-microsof t-com : datatypes"> 

<REF_TBL> 

<REF> 

<REF_ID>1800000000</REF_ID> 

<FORMAT_CODE>NOS</FORMAT_CODE> 

<DESCR_TXT>MAR  TP-1  VBE-B  OCXS  Data  Fill</DESCR_TXT> 
<SECURITY_CLSFC_CODE>NU</SECURITY_CLSFC_CODE> 
<SOURCE_TXT>Scenario  1 . xml</SOURCE_TXT> 
<TRANS_TYPE_CODE>EMLMSG</TRANS_TYPE_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</REF> 

</REF_TBL> 

Figure  3.  The  reference  table  is  the  first  table  to  be  filled  in  the  data  load.  This  table  represents 

a  reference  to  the  information  source  used  in  the  reporting. 


4.1.2  Coalition  Objects 

The  next  data  to  be  loaded  pertains  to  the  objects  known  by  the  coalition  forces.  These 
objects  are  identified  by  information  in  the  OBJ  ITEM  (object-item)  table.  In 
LC2IEDM,  object  items  are  made  up  of  individually  identifiable  objects  that  have 
military  significance.  The  objects  must  fall  into  one  of  the  following  categories:  a 
facility,  a  feature,  materiel,  an  organisation  or  a  person  [12]. 

For  this  description,  the  data  load  is  broken  into  two  parts.  Part  one  is  represented  in 
Figure  4  and  describes  individual  materiel  units  in  the  battlespace.  For  the  VBE,  these 
units  are  represented  by  the  various  platforms  known  at  the  start  of  the  experiment. 

The  known  platforms  include  the  coalition  surface  ships  TeKaha  and  Halifax,  the 
submarine  Sheean  and  the  UAV.  For  each  unit,  the  <CAT_CODE>  (category-code) 
indicates  the  objects  are  materiel. 

The  scenario  also  contains  two  hostile  patrol  frigates.  These  are  indicated  in  Figure  4 
by  the  two  records  containing  the  <NAME>  “FFG1  ”  and  “FFG2”.  Based  on  the 
scenario  description,  the  platforms  (or  object  items  in  LC2IEDM  terminology)  are 
known  to  be  in  the  area,  and  therefore  it  is  reasonable  to  include  the  items  in  the  initial 
data  load.  Note  that  including  the  item  at  this  stage  simply  recognises  the  possible 
existence  of  the  item  in  the  area  of  operation. 
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<OBJ_ITEM_TBL> 

<OBJ_ITEM> 

<OBJ_ITEM_ID>2800000000</OBJ_ITEM_ID> 

<CAT_CODE>MA< / CAT_CODE> 

<NAME>TeKaha</NAME> 

<ALTN_I DENT I F I C_TXT / > 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</OBJ_ITEM> 

<OBJ_ITEM> 

<0B J_I TEM_I D>2801000000  < /OB J_I TEM_I D> 

<CAT_CODE>MA< / CAT_CODE> 

<NAME>Sheean</NAME> 

<ALTN_I DENT I F I C_TXT / > 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM> 

<OBJ_ITEM> 

<OBJ_ITEM_ID>2802000000</OBJ_ITEM_ID> 

<CAT_CODE>MA</CAT_CODE> 

<NAME>UAV</NAME> 

<ALTN_I DENT I F I C_TXT / > 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</OBJ_ITEM> 

<OBJ_ITEM> 

<OBJ_ITEM_ID>2803000000</OBJ_ITEM_ID> 

<CAT_CODE>MA< / CAT_CODE> 

<NAME>Halifax</NAME> 

<ALTN_I DENT I F I C_TXT / > 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</OBJ_ITEM> 

<OBJ_ITEM> 

<OB J_I TEM_I D>1801000000</OBJ_I TEM_I D> 

<CAT_CODE>MA</CAT_CODE> 

<NAME>FFG1</NAME> 

<ALTN_IDENTIFIC_TXT>FFG1</ALTN_IDENTIFIC_TXT> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM> 

<OBJ_ITEM> 

<OBJ_ITEM_ID>1801000001</OBJ_ITEM_ID> 

<CAT_CODE>MA< / CAT_CODE> 

<NAME>FFG2</NAME> 

<ALTN_IDENTIFIC_TXT>FFG2</ALTN_IDENTIFIC_TXT> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</OBJ_ITEM> 

Figure  4.  The  first  series  of  records  for  the  object-item  tabie  indicates  the  materiei  units  or 

piatforms  used  within  the  VBE.  This  ioad  inciudes  friendiy  and  hostiie  units,  however,  no 
distinction  between  friendiy  and  hostiie  units  is  made  at  this  time. 
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The  second  series  of  records  to  be  added  to  the  object-item  table  pertain  to 
organisational  information  (Figure  5).  Organisations  are  indicated  by  the 
<CAT_CODE>  “OR”,  which  indicates  “an  object-item  that  is  administrative  or 
functional  structure”  [12],  In  this  experiment,  the  loaded  organisations  represent 
command  structures  used  in  the  VBE. 


<OBJ_ITEM> 

<OBJ_ITEM_ID>2805000000</OBJ_ITEM_ID> 

<CAT_CODE>OR</CAT_CODE> 

<NAME>FFH2  Command</NAME> 

<ALTN_I DENT I F I C_TXT / > 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM> 

<OBJ_ITEM> 

<OBJ_ITEM_ID>2806000000</OBJ_ITEM_ID> 

<CAT_CODE>OR< / CAT_CODE> 

<NAME>Sheean  Command</NAME> 

<ALTN_IDENTIFIC_TXT/> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</OBJ_ITEM> 

<OBJ_ITEM> 

<OB J_I TEM_I D>2807000000  < /OB J_I TEM_I D> 

<CAT_CODE>OR</CAT_CODE> 

<NAME>UAV  Command</NAME> 

<ALTN_I DENT I F I C_TXT / > 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM> 

<OBJ_ITEM> 

<OBJ_ITEM_ID>2808000000</OBJ_ITEM_ID> 

<CAT_CODE>OR</CAT_CODE> 

<NAME>FFH1  Command</NAME> 

<ALTN_IDENTIFIC_TXT/> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</OBJ_ITEM> 

<OBJ_ITEM> 

<OB J_I TEM_I D>2810000000  < /OB J_I TEM_I D> 

<CAT_CODE>OR< / CAT_CODE> 

<NAME>TP-1  Coalition  Commands r</NAME> 

<ALTN_I DENT I F I C_TXT / > 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM> 

</OBJ_ITEM_TBL> 

Figure  5.  The  second  series  of  records  for  the  object-item  table  indicates  the  organisations 

within  the  VBE.  Here,  the  command  structures  are  identified. 
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4.1.3  Materiel 


The  next  part  of  the  data  load  deals  with  the  MAT  (materiel)  table.  Materiel  is  one 
form  of  an  object  item.  The  materiel  table  is  defined  as  “An  OBJECT-ITEM  that  is 
equipment,  apparatus  or  supplies  of  military  interest  without  distinction  as  to  its 
application  for  administrative  or  combat  purposes”[12].  This  indicates  that  the 
materiel  record  pertains  to  both  friendly  and  hostile  materiel  units. 

The  materiel  table  is  the  first  table  encountered  in  the  load  that  represents  a 
specialization  in  the  data  model.  Specializations  are  a  form  of  business  rule  that  may 
be  included  in  entity-relationship  (ER)  modelling  [27].  Specializations  indicate  the 
increased  specific  definition  of  an  object.  The  enforcement  of  specializations  is 
typically  included  in  software  systems  used  to  interact  with  the  database.  In  the 
LC2IEDM  Canadian  implementation,  the  enforcement  of  specializations  is  included  at 
the  API  level  used  to  interact  with  the  database  [28].  This  API  level  is  known  as  the 
Data  Services  Layer  (DSL). 

In  the  present  case,  the  information  indicated  in  object-item  is  further  specified  by  the 
information  in  the  materiel  table.  This  may  be  illustrated  by  considering  Figure  4  in 
conjunction  with  Figure  6.  In  Figure  4  we  see  the  <OBJ_ITEM_ID>  of 
“2800000000”  representing  the  TeKaha  platform.  Also  note  that  this  information 
pertains  to  <CAT_CODE>  of  “MA”  indicating  materiel.  In  the  materiel  table,  the  same 
identifier  value  for  the  <MAT_ID>  forms  the  link  between  the  two  records.  The 
materiel  record  then  describes  the  visual  identifiers  for  the  materiel  unit.  The  first 
record,  which  pertains  to  information  for  the  TeKaha,  indicates  the  unit  is  “GREY”. 

The  <MARKING_CODE>  content  of  “NOS”  indicates  that  any  markings  are  not  part 
of  the  standard  list  available  for  this  code.  The  standard  list  is:  numbers,  stripe,  stripes, 
symbols,  writing,  or  not  known  [13].  The  <MARKING_COLOUR_CODE>  indicates 
the  colour  of  any  identified  markings.  Again,  “NOS”  indicates,  “the  appropriate  value 
is  not  in  the  set  of  specified  values”  [13]. 

Each  of  the  coalition  object  items  identified  in  Figure  4  are  listed  in  Figure  6.  This  is 
because  the  characteristics  of  these  platforms  are  known  by  coalition  personnel  and 
thus  may  be  loaded  into  the  database  at  the  start-up  of  the  experiment.  Similar 
information  on  the  hostile  frigates  is  not  known  at  start-up.  This  is  because  the 
coalition  has  no  available  information  on  the  hostile  frigates  within  the  scenario 
description  [8]. 
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<MAT_TBL> 

<MAT> 

<MAT_ID>2800000000</MAT_ID> 

<SERIAL_NO_ID_TXT/> 

<LOT_I DENT I F I C_TXT / > 

<BODY_COLOUR_CODE>GREY</BODY_COLOUR_CODE> 

<MARKING_CODE>NOS</MARKING_CODE> 

<MARKING_COLOUR_CODE>NOS</MARKING_COLOUR_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</MAT> 

<MAT> 

<MAT_ID>2801000000</MAT_ID> 

<SERIAL_NO_ID_TXT/> 

<LOT_I DENT I F I C_TXT / > 

<BODY_COLOUR_CODE>BLACK</BODY_COLOUR_CODE> 

<MARKING_CODE>NOS</MARKING_CODE> 

<MARKING_COLOUR_CODE>NOS</MARKING_COLOUR_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</MAT> 

<MAT> 

<MAT_ID>2802000000</MAT_ID> 

<SERIAL_NO_ID_TXT/> 

<LOT_I DENT I F I C_TXT / > 

<BODY_COLOUR_CODE>WHITE</BODY_COLOUR_CODE> 

<MARKING_CODE>NOS</MARKING_CODE> 

<MARKING_COLOUR_CODE>NOS</MARKING_COLOUR_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</MAT> 

<MAT> 

<MAT_ID>2803000000</MAT_ID> 

<SERIAL_NO_ID_TXT/> 

<LOT_I DENT I F I C_TXT / > 

<BODY_COLOUR_CODE>GREY</BODY_COLOUR_CODE> 

<MARKING_CODE>NOS</MARKING_CODE> 

<MARKING_COLOUR_CODE>NOS</MARKING_COLOUR_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</MAT> 

</MAT_TBL> 

Figure  6.  The  materiel  table  is  a  specialization  of  the  object-item.  The  materiel  indicates  the 

colour  markings  of  the  materiel  platforms  listed  in  the  object-item  table.  Only  the  coalition 
platform’s  markings  are  indicated  in  this  figure,  because  no  information  is  available  on  the 
markings  of  the  hostile  frigates. 
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4.1.4  Organisations 


The  ORG  (organisation)  table  (Figure  7)  is  another  specialization  of  an  object-item. 
The  organisation  table  tracks  and  describes  the  organizations.  In  this  VBE,  the 
organizations  are  identified  in  Figure  5.  Note  that  the  <OBJ_lTEM_lD>  in  Figure  5 
matches  the  <0RG_1D>  from  Figure  7.  In  the  record  for  the  organization  table,  the 
<CAT_CODE>  of  “UN”  indicates  a  military  unit.  A  military  unit  is  defined  as  “A 
military  ORGANISATION  whose  structure  is  prescribed  by  competent  authority”[12]. 

In  this  particular  case,  only  one  organisation  is  given  a  name.  The  final  record  in 
Figure  7  identifies  the  Task  Force  (TF)  TTCP  Blue.  This  indicates  that  the  coalition 
command  structure  has  a  nickname  of  “TF  TTCP  Blue”. 

<ORG_TBL> 

<ORG> 

<ORG_ID>2805000000</ORG_ID> 

<CAT_CODE>UN</CAT_CODE> 

<N I CKNAME_NAME / > 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</ORG> 

<ORG> 

<ORG_ID>2806000000</ORG_ID> 

<CAT_CODE>UN< / CAT_CODE> 

<N I CKNAME_NAME / > 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</ORG> 

<ORG> 

<ORG_ID>2807000000</ORG_ID> 

<CAT_CODE>UN</CAT_CODE> 

<N I CKNAME_NAME / > 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</ORG> 

<ORG> 

<ORG_ID>2808000000</ORG_ID> 

<CAT_CODE>UN</CAT_CODE> 

<N I CKNAME_NAME / > 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</ORG> 

<ORG> 

<ORG_ID>2810000000</ORG_ID> 

<CAT_CODE>UN< / CAT_CODE> 

<NICKNAME_NAME>TF  TTCP  Blue</NICKNAME_NAME> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</ORG> 

</ORG_TBL> 

Figure  7.  The  organisation  table  is  another  specialization  of  object  item. 
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4.1.5  Military  Units 


The  organisation  table  has  identified  the  military  units.  These  units  are  further 
described  in  the  UNIT  (unit)  table.  The  unit  table  is  one  entity  in  an  incomplete 
specialization  definition  for  the  organisation  table.  The  other  entity  in  the 
specialization  is  convoy. 

The  unit  table  content  is  shown  in  Figure  8.  The  <UNIT_ID>  is  linked  back  to  the 
<ORG_ID>  in  Figure  7.  Thus,  the  organization  defined  with  identifier  “2805000000” 
corresponds  to  the  military  unit  “FFH2”  which  is  the  coalition  frigate  command 
organisation,  as  indicated  by  Figure  5.  The  remaining  records  in  the  unit  table  identify 
the  command  structures  for  the  Sheean,  UAV,  FFHl  and  the  TTCP  Commander. 


<UNIT_TBL> 

<UNIT> 

<UNIT_ID>2805000000</UNIT_ID> 

<FORMAL_ABBRD_NAME>FFH2</FORMAL_ABBRD_NAME> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</UNIT> 

<UNIT> 

<UNIT_ID>2806000000</UNIT_ID> 

<FORMAL_ABBRD_NAME>Sheean</FORMAL_ABBRD_NAME> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</UNIT> 

<UNIT> 

<UNIT_ID>2807000000</UNIT_ID> 

<FORMAL_ABBRD_NAME>UAV</FORMAL_ABBRD_NAME> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</UNIT> 

<UNIT> 

<UNIT_ID>2808000000</UNIT_ID> 

<  FORMAL_ABBRD_NAME  >  F  FH 1  <  /  FORMAL_ABBRD_NAME  > 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</UNIT> 

<UNIT> 

<UNIT_ID>2810000000</UNIT_ID> 

<FORMAL_ABBRD_NAME>CTFC  TTCP  Blue</FORMAL_ABBRD_NAME> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</UNIT> 

</UNIT_TBL> 

Figure  8.  The  unit  table  is  part  of  an  incomplete  specialization  of  an  organisation.  For  VBE-B, 

each  organisation  is  considered  a  military  unit. 
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4.1.6  The  Association  Between  Organisation  and  Materiel 


Next,  the  relationship  between  organization  and  materiel  is  specified  (Figure  9).  This 
is  done  via  the  ORG_MAT_ASSOC  (organization-material-association)  table.  Note 
that  version  5.0  of  the  model  contains  this  particular  table,  while  version  5.3  does  not. 

The  organization-material-association  table  indicates  the  relationship  between  an 
organisation  and  a  materiel  object.  Here,  the  <SUB_ORG_ID>  provides  a  link  back  to 
the  organisation  table.  This  link  defines  the  subject  (thus  SUB)  of  the  relationship. 
The  <OBJ_MAT_ID>  provides  the  link  back  to  the  object.  In  this  way,  the  object  is 
associated  with  a  particular  organisation.  More  than  one  association  can  exist,  as  one 
object  can  be  part  of  more  than  one  organisation. 

In  this  particular  load,  all  records  have  a  <CAT_CODE>  containing  “CONTRL”.  The 
definition  of  this  code  is  “A  specific  ORGANISATION  controls  an  item  of  Materiel” 
[13]. 


4.1 .7  Types  of  Objects 

The  object  type  information  (see  Figure  10)  may  be  considered  high-level  metadata 
pertaining  to  the  class  of  objects  defined  in  the  object-item  table.  One  method  of 
distinguishing  the  object  item  and  object  type  is  to  remember  that  an  object  type 
cannot  have  an  associated  quantity.  This  is  because  object  types  are  categories  or 
classes  of  objects,  while  object  items  are  actually  countable  objects. 

The  first  part  of  the  object-type  load  contains  records  that  have  <CAT_CODE>  of 
“MA”  indicating  Materiel.  The  first  record  indicates  a  UK  object  as  indicated  by 
<NATIONALITY_CODE>  of  “UK”.  The  object  is  named  “Type45”.  This  is  the 
Daring  Class  destroyer  planned  to  enter  service  in  the  UK  in  2007. 

The  second  record  has  <OBJ_TYPE_ID>  of  “3801 000000”  and  accounts  for  the 
Australian  Collins  class  submarine.  The  UAV  is  described  in  the  third  record,  and  is 
noted  to  be  from  New  Zealand  and  of  type  Predator.  The  final  record  indicates  the 
Canadian  Halifax  class  Frigate.  Note  that  both  coalition  ships  are  Halifax  Class 
frigates. 

The  second  part  of  the  object  type  indicates  the  organisational  units  (see  Figure  11). 
The  <CAT_CODE>  of  “OR”  is  defined  as  “An  OBJECT-TYPE  that  represents 
administrative  or  functional  structures”  [13].  These  organisations  represent  the 
command  structures  associated  with  the  platforms. 
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<ORG_MAT_ASSOC_TBL> 

<ORG_MAT_ASSOC> 

<SUBJ_ORG_ID>2805000000</SUBJ_ORG_ID> 

<0B J_MAT_I D> 28000000  0  0</OB J_MAT_I D> 

<ORG_MAT_AS  SOC_I X> 1 < / ORG_MAT_AS  SOC_I X> 
<CAT_CODE>CONTRL</CAT_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</ORG_MAT_ASSOC> 

<ORG_MAT_ASSOC> 

<SUBJ_ORG_ID>2806000000</SUBJ_ORG_ID> 

<OB J_MAT_I D> 28010000  0  0</OB J_MAT_I D> 

<ORG_MAT_AS  SOC_I X> 1 < / ORG_MAT_AS  SOC_I X> 
<CAT_CODE>CONTRL</CAT_CODE> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</ORG_MAT_ASSOC> 

<ORG_MAT_ASSOC> 

<SUBJ_ORG_ID>2807000000</SUBJ_ORG_ID> 

<OBJ_MAT_ID>2802000000</OBJ_MAT_ID> 

<ORG_MAT_AS  SOC_I X> 1 < / ORG_MAT_AS  SOC_I X> 
<CAT_CODE>CONTRL</CAT_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</ORG_MAT_ASSOC> 

<ORG_MAT_ASSOC> 

<SUB J_ORG_I D>28080000  0  0</ SUB J_ORG_I D> 
<OBJ_MAT_ID>2803000000</OBJ_MAT_ID> 

<ORG_MAT_AS  SOC_I X> 1 < / ORG_MAT_AS  SOC_I X> 
<CAT_CODE>CONTRL</CAT_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</ORG_MAT_ASSOC> 

</ORG_MAT_ASSOC_TBL> 

Figure  9.  The  organisation-materiel-association  table  establishes  the  relations  between  specific 

organisations  and  materiel.  In  this  case,  materiel  belongs  to  specific  organisations.  This 
is  indicated  by  the  “controls”  category-code  value. 
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<OBJ_TYPE_TBL> 

<OBJ_TYPE> 

<0B J_TYPE_I D>38000000  0  0</OB J_TYPE_I D> 
<CAT_CODE>MA</CAT_CODE> 

<DUMMY_IND_CODE>NO</DUMMY_IND_CODE> 

<NAME>Type45</NAME> 

<NATIONALITY_CODE>UK</NATIONALITY_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_TYPE> 

<OBJ_TYPE> 

<0B J_TYPE_I D>38010000  0  0</OB J_TYPE_I D> 
<CAT_CODE>MA</CAT_CODE> 

<DUMMY_IND_CODE>NO</DUMMY_IND_CODE> 

<NAME>Collins</NAME> 

<NAT I ONAL I T Y_CODE>AS  < /NAT I ONAL I T Y_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_TYPE> 

<OBJ_TYPE> 

<OBJ_TYPE_ID>3802000000</OBJ_TYPE_ID> 

<CAT_CODE>MA</CAT_CODE> 

<DUMMY_IND_CODE>NO</DUMMY_IND_CODE> 

<NAME>PredatorNZ</NAME> 

<NAT  I  ONAL  I T  Y_CODE>N  Z  <  /NAT  I  ONAL  I T  Y_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_TYPE> 

<OBJ_TYPE> 

<OBJ_TYPE_ID>3803000000</OBJ_TYPE_ID> 

<CAT_CODE>MA< / CAT_CODE> 

<DUMMY_IND_CODE>NO</DUMMY_IND_CODE> 

<NAME>Halifax</NAME> 

<NATIONALITY_CODE>CA</NATIONALITY_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</OBJ_TYPE> 

Figure  10.  The  first  part  of  the  object-type  tables  identifies  the  various  classes  of  physical 

objects  in  the  scenario. 
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<OBJ_TYPE> 

<OBJ_TYPE_ID>3805000000</OBJ_TYPE_ID> 

<CAT_CODE>OR</CAT_CODE> 

<DUMMY_IND_CODE>NO</DUMMY_IND_CODE> 

<NAME>Naval  Combatant</NAME> 

<NAT I ONAL I T Y_CODE>UK< /NAT I ONAL I T Y_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_TYPE> 

<OBJ_TYPE> 

<OBJ_TYPE_ID>3806000000</OBJ_TYPE_ID> 

<CAT_CODE>OR</CAT_CODE> 

<DUMMY_IND_CODE>NO</DUMMY_IND_CODE> 

<NAME>Naval  Combatant</NAME> 

<NAT I ONAL I T Y_CODE>AS  < /NAT I ONAL I T Y_CODE> 
<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_TYPE> 

<OBJ_TYPE> 

<OBJ_TYPE_ID>3807000000</OBJ_TYPE_ID> 

<CAT_CODE>OR< / CAT_CODE> 
<DUMMY_IND_CODE>NO</DUMMY_IND_CODE> 

<NAME>Unmanned  Air  Vehicle  Squadron</NAME> 

<NATIONALIT  Y_CO  DE  >N  Z  </NATIONALIT  Y_CO  DE  > 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</OBJ_TYPE> 

<OBJ_TYPE> 

<OB J_TYPE_I D>38080000  0  0</OB J_TYPE_I D> 

<CAT_CODE>OR< / CAT_CODE> 
<DUMMY_IND_CODE>NO</DUMMY_IND_CODE> 

<NAME>Naval  Combatant</NAME> 
<NATIONALITY_CODE>CA</NATIONALITY_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</OBJ_TYPE> 

<OBJ_TYPE> 

<OB J_TYPE_I D>38100000  0  0</OB J_TYPE_I D> 

<CAT_CODE>OR</CAT_CODE> 

<DUMMY_IND_CODE>NO</DUMMY_IND_CODE> 

<NAME>CTF  Commander </NAME> 
<NATIONALITY_CODE>AS</NATIONALITY_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_TYPE> 

</OBJ_TYPE_TBL> 

Figure  1 1.  The  second  part  of  the  object-type  table.  This  part  of  the  table  identifies  the 

administrative  and  functional  structures. 
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4.1 .8  Types  of  Materiel 


The  four  classes  or  object  types  identified  in  Figure  10  are  further  expanded  in 
Figure  12.  The  <MAT_TYPE_ID>  links  back  to  the  <OBJ_TYPE_ID>  from 
Figure  10.  In  all  records  shown  for  the  MAT  TYPE  (materiel-type)  table,  the 
category-code  is  “EQ”  indicating  equipment. 

The  remaining  fields  are  blank,  but  should  nevertheless  be  noted.  The 
reportable-item-text  (<RPTBL_ITEM_TXT>)  references  the  Reportable  Item  Code 
list  issued  by  NATO.  The  stock-number-text  (<STOCK_NO_TXT>)  represents  the 
NATO  stock  number.  The  supply-class-code  (<SUPPLY_CLASS_CODE>) 
represents  the  NATO  class  of  the  materiel  [29,  30]. 


4.1 .9  Types  of  Equipment 

The  EQPT_TYPE  (equipment-type)  table  is  shown  in  Figure  13.  Equipment-type 
represents  one  entity  in  the  incomplete  specialization  of  the  materiel-type  entity  -  the 
other  entity  being  consumable-material-type  (not  used  in  this  experiment).  The 
equipment-type  is  linked  to  the  materiel-type  via  the  relationship  between 
<EQPT_TYPE_ID>  and  <MAT_TYPE_ID>.  The  equipment-type  records  indicate 
that  the  equipment  is  actually  three  vessels  and  an  aircraft. 

The  category-code  in  the  equipment-type  table  subdivides  the  equipment  into  more 
specific  groups.  The  <CAT_CODE>  of  “VESSEL”  is  defined  as  ‘‘An  EQUIPMENT- 
TYPE  that  is  designed  to  operate  on  or  under  the  water  surface”  [13]  and  thus  includes 
a  submarine.  Recall  that  the  submarine  is  indicated  using  <EQPT_TYPE_ID>  of 
“3801 000000”.  The  loaded  and  unloaded  weight  of  the  equipment  may  be  described 
in  the  equipment-type  record,  as  well  as  height,  width  and  length  dimensions. 

Equipment-type  is  further  specified  by  a  complete  specialization  in  the  ER  logical 
model.  The  specializations  include  entities  for  aircraft,  electronics,  engineering,  land 
weapons,  nuclear-biological-chemical  (NBC)  equipment,  railcars,  vehicles,  vessels  and 
miscellaneous  equipment. 
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<MAT_TYPE_TBL> 

<MAT_TYPE> 

<MAT_T YPE_I D>3800000000  < /MAT_T YPE_I D> 

<CAT_CODE>EQ</CAT_CODE> 

<RPTBL_ITEM_TXT></RPTBL_ITEM_TXT> 

<STOCK_NO_TXT></STOCK_NO_TXT> 

<SUPPLY_CLASS_CODE></SUPPLY_CLASS_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</MAT_TYPE> 

<MAT_TYPE> 

<MAT_T YPE_I D>3801000000  < /MAT_T YPE_I D> 

<CAT_CODE>EQ</CAT_CODE> 

<RPTBL_ITEM_TXT></RPTBL_ITEM_TXT> 

<STOCK_NO_TXT></STOCK_NO_TXT> 

<SUPPLY_CLASS_CODE></SUPPLY_CLASS_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</MAT_TYPE> 

<MAT_TYPE> 

<MAT_TYPE_I D>3802000000  < /MAT_TYPE_I D> 

<CAT_CODE>EQ</CAT_CODE> 

<RPTBL_ITEM_TXT></RPTBL_ITEM_TXT> 

<STOCK_NO_TXT></STOCK_NO_TXT> 

<SUPPLY_CLASS_CODE></SUPPLY_CLASS_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</MAT_TYPE> 

<MAT_TYPE> 

<MAT_TYPE_I D>3803000000  < /MAT_TYPE_I D> 

<CAT_CODE>EQ</CAT_CODE> 

<RPTBL_ITEM_TXT></RPTBL_ITEM_TXT> 

<STOCK_NO_TXT></STOCK_NO_TXT> 

<SUPPLY_CLASS_CODE></SUPPLY_CLASS_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</MAT_TYPE> 

</MAT_TYPE_TBL> 

Figure  12.  The  materiel-type  table  indicates  the  details  of  the  materiel  object  types.  The  materiel 

objects  are  shown  in  Figure  10. 
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<EQPT_TYPE_TBL> 

<EQPT_TYPE> 

<EQPT_TYPE_I D>38000000  0  0</EQPT_TYPE_I D> 
<CAT_CODE>VESSEL</CAT_CODE> 

<LOADED_WT_QTY>< / LOADED_WT_QTY> 

<UNLOADED_WT_QT Y>  0  < / UNLOADED_WT_QT Y> 

<MAX_HE I GHT_D IMX /MAX_HE I GHT_D IM> 
<MAX_LENGTH_DIM></MAX_LENGTH_DIM> 

<MAX_W IDTH_DIM></ MAX_W IDTH_DIM> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</EQPT_TYPE> 

<EQPT_TYPE> 

<EQPT_TYPE_I D>38010000  0  0</EQPT_TYPE_I D> 
<CAT_CODE>VESSEL</CAT_CODE> 

<LOADED_WT_QTY>< / LOADED_WT_QTY> 
<UNLOADED_WT_QTY>0</UNLOADED_WT_QTY> 

<MAX_HE I GHT_D IMX /MAX_HE I GHT_D IM> 
<MAX_LENGTH_DIMX/MAX_LENGTH_DIM> 
<MAX_WIDTH_DIMX/MAX_WIDTH_DIM> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</EQPT_TYPE> 

<EQPT_TYPE> 

<EQPT_TYPE_ID>38  02  0  000  0  0</EQPT_TYPE_ID> 
<CAT_CODE>AIRCFT</CAT_CODE> 

<LOADED_WT_QTYX/LOADED_WT_QTY> 

<UNLOADED_WT_QTY>0</UNLOADED_WT_QTY> 

<MAX_HE I GHT_D IMX /MAX_HE I GHT_D IM> 
<MAX_LENGTH_DIMX/MAX_LENGTH_DIM> 
<MAX_WIDTH_DIMX/MAX_WIDTH_DIM> 

<OWNER_I D> I < / OWNER_I D> 

<UPDATE_SEQNR>I</UPDATE_SEQNR> 

</EQPT_TYPE> 

<EQPT_TYPE> 

<EQPT_TYPE_ID>38  030  0  0  0  0  0</EQPT_TYPE_ID> 
<CAT_CODE>VESSEL</CAT_CODE> 

<LOADED_WT_QTYX/LOADED_WT_QTY> 

<UNLOADED_WT_QTY>0</UNLOADED_WT_QTY> 

<MAX_HE  I  GHT_D  I  MX  /  MAX_HE  I  GHT_D  I  M> 
<MAX_LENGTH_DIMX/MAX_LENGTH_DIM> 

<MAX_W  IDTH_DIMX  /  MAX_W  IDTH_DIM> 

<OWNER_I D> I < / OWNER_I D> 

<UPDATE_SEQNR>I</UPDATE_SEQNR> 

</EQPT_TYPE> 

</EQPT_TYPE_TBL> 

Figure  13.  The  equipment-type  tabie  further  specifics  the  materiei  types.  Note  that  the  vessei’s 

weight  and  dimensions  couid  have  been  specified. 
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4.1.10  Vessels  and  Aircraft 


Each  identified  piece  of  equipment  is  then  described  using  the  vessel-type  or  the 
aircraft-type  tables  (Figure  14).  In  both  cases,  the  identifier  (<VESSEL_TYPE_ID> 
or  <ACFT_TYPE_ID>)  is  linked  back  to  the  EQPT  TYPE  table.  The  <CAT_CODE> 
in  Figure  13  determines  the  specialization. 

In  the  vessel  Jype  table,  the  <CAT_CODE>  indicates  if  the  vessel  is  a  surface  or 
subsurface  unit.  The  “SUBSRF”  indicates  subsurface.  The  subcategory-code 
(<SUBCAT_CODE>)  represents  a  specific  class  of  vessel.  A  total  of  61 
subcategory-codes  exist  for  vessel,  including  such  diverse  items  such  as  barrage,  raft, 
and  tug  boat.  In  this  experiment,  the  data  load  includes  “FRIGAT”  and  “SUBATT” 
indicating  a  Frigate  and  an  attack  submarine. 

In  the  aircraft-type  entity  the  category-code  indicates  a  fixed  wing  aircraft.  The 
subcategory-code  indicates  an  UAV. 

<VESSEL_TYPE_TBL> 

<VESSEL_TYPE> 

<VESSEL_TYPE_ID>3800000000</VESSEL_TYPE_ID> 

<CAT_CODE>SURFAC< / CAT_CODE> 

<SUBCAT_CODE>FRIGAT</SUBCAT_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</VESSEL_TYPE> 

<VESSEL_TYPE> 

<VESSEL_TYPE_I D>38010000  0  0</VESSEL_TYPE_I D> 
<CAT_CODE>SUBSRF</CAT_CODE> 

<SUBCAT_CODE>SUBATT</SUBCAT_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</VESSEL_TYPE> 

<VESSEL_TYPE> 

<VESSEL_TYPE_ID>3803000000</VESSEL_TYPE_ID> 

<CAT_CODE>SUBSRF</CAT_CODE> 

<SUBCAT_CODE>FRIGAT</SUBCAT_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</VESSEL_TYPE> 

</VESSEL_TYPE_TBL> 

<ACFT_TYPE_TBL> 

<ACFT_TYPE> 

<AC  FT_T Y  PE_I D>3802000000  < / AC  FT_T Y  PE_I D> 
<CAT_CODE>FIXWNG</CAT_CODE> 

<SUBCAT_CODE>UAV</SUBCAT_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</ACFT_TYPE> 

</ACFT_TYPE_TBL> 

Figure  14.  The  vessel  and  aircraft  materiel  objects  are  further  specified  by  the  complete 

specialization.  In  this  case,  the  vessel-type  and  aircraft-type  tables  are  used. 
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4.1.11  Types  of  Organisations 

The  object-types  defined  in  Figure  1 1  dealt  with  organisation  objects.  These  objects 
are  further  described  using  the  ORG  TYPE  (organisation-type)  table  shown  in 
Figure  15. 

The  <ORG_TYPE_ID>  provides  the  link  back  to  the  <OBJ_TYPE_ID>  in  Figure  11. 
Each  organisation  is  identified  using  <CAT_CODE>  as  “GVTORG”  which  is  defined 
in  the  data  model  as  “An  ORGANISATION-TYPE  that  controls  and  administers 
public  policy  either  under  a  national  or  international  mandate”  [13]. 


4.1.12  Government  Organisations 

Each  organisation-type  was  identified  as  government.  These  organisations  are  then 
further  specified  using  the  GOVT  ORG  TYPE  (government-organisation-type)  table 
(Figure  16).  The  <GOVT_ORG_TYPE_ID>  is  linked  back  to  the  <ORG_TYPE_ID> 
In  each  record  in  Figure  16,  the  government  organisation  is  identified  as  “MILORG” 
which  is  defined  as  “A  GOVERNMENT-ORGANISATION-TYPE  that  is  officially 
sanctioned  and  is  trained  and  equipped  to  exert  force”  [13]. 

The  <MAIN_ACTIVITY_CODE>  describes  the  main  function  of  the  government 
organisation.  This  field  is  “NOS”  representing  “not  otherwise  specified”. 
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<ORG_TYPE_TBL> 

<ORG_TYPE> 

<ORG_TYPE_ID>3805000000</ORG_TYPE_ID> 

<CAT_CODE>GVTORG</CAT_CODE> 

<DESCR_TXT>Naval  Unit</DESCR_TXT> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</ORG_TYPE> 

<ORG_TYPE> 

<ORG_TYPE_I D>3  8  06000000  < /ORG_TYPE_I D> 

<CAT_CODE>GVTORG< / CAT_CODE> 

<DESCR_TXT>Naval  Unit</DESCR_TXT> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</ORG_TYPE> 

<ORG_TYPE> 

<ORG_TYPE_ID>3807000000</ORG_TYPE_ID> 

<CAT_CODE>GVTORG</CAT_CODE> 

<DESCR_TXT>Naval  Unit</DESCR_TXT> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</ORG_TYPE> 

<ORG_TYPE> 

<ORG_TYPE_I D>38080000  0  0</ORG_TYPE_I D> 

<CAT_CODE>GVTORG< / CAT_CODE> 

<DESCR_TXT>Naval  Unit</DESCR_TXT> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</ORG_TYPE> 

<ORG_TYPE> 

<ORG_T YPE_I D>3810000000</ ORG_T YPE_I D> 
<CAT_CODE>GVTORG</CAT_CODE> 

<DESCR_TXT>Coalition  TF  Commander</DESCR_TXT> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</ORG_TYPE> 

</ORG_TYPE_TBL> 

Figure  15.  The  organisation-type  table  is  part  of  the  complete  specialization  structure  under 

object-type. 
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<  GOVT_ORG_T  Y  PE_TB  L  > 

<  GOVT_ORG_T  Y  PE  > 

<GOVT_ORG_T Y  PE_I D>3805000000</ GOVT_ORG_T Y  PE_I D> 
<CAT_CODE>MILORG</CAT_CODE> 

<MAIN_ACTIVITY_CODE>NOS</MAIN_ACTIVITY_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

< / GOVT_ORG_T Y  PE > 

<  GOVT_ORG_T  Y  PE  > 

<GOVT_ORG_TYPE_I D>3  8  06000000</ GOVT_ORG_TYPE_I D> 

<CAT_CODE>MI LORG< / CAT_CODE> 

<MAIN_ACTIVITY_CODE>NOS</MAIN_ACTIVITY_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

< / GOVT_ORG_TYPE> 

<GOVT_ORG_TYPE> 

<GOVT_ORG_T Y  PE_I D>3807000000</ GOVT_ORG_T Y  PE_I D> 
<CAT_CODE>MILORG</CAT_CODE> 

<MAIN_ACTIVITY_CODE>NOS</MAIN_ACTIVITY_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

< / GOVT_ORG_T Y  PE > 

<  GOVT_ORG_T  Y  PE  > 

<GOVT_ORG_T Y  PE_I D>3808000000</ GOVT_ORG_T Y  PE_I D> 

<CAT_CODE>MI LORG< / CAT_CODE> 

<MAIN_ACTIVITY_CODE>NOS</MAIN_ACTIVITY_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

< / GOVT_ORG_T Y  PE > 

<GOVT_ORG_TYPE> 

<GOVT_ORG_TYPE_I D>3810000000</ GOVT_ORG_TYPE_I D> 
<CAT_CODE>MILORG</CAT_CODE> 

<MAIN_ACTIVITY_CODE>NOS</MAIN_ACTIVITY_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

< / GOVT_ORG_TYPE> 

</GOVT_ORG_TYPE_TBL> 

Figure  16.  The  government-organisation-type  tabie  is  one  table  in  an  incomplete  specialization  of 

the  organisation-type. 


4.1.13  Military  Organisations 

The  military  organisations  identified  in  Figure  16  are  further  detailed  in  Figure  17. 
The  MIL  ORG  TYPE  (military-organisation-type)  table  specifies  that  each  military 
organisation  may  be  considered  a  single  unit,  as  indicated  by  the  <CAT_CODE>  of 
“UNIT”.  Other  categories  include  the  executive  military  organisation,  task  formation 
organisation,  and  a  military  posting.  The  military  posting  applies  to  a  single  person, 
while  the  other  codes  apply  to  groups. 
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The  <SERVICE_CODE>  represents  the  type  of  group  that  is  considered  the  military 
organisation.  The  service-code  definition  is  “The  specific  value  that  represents  a 
military,  paramilitary,  or  irregular  force  or  group  capable  of  functioning  as  an 
offensive  or  defensive  combat  or  support  organisation”  [13],  The  domain  allows 
content  including  specifications  for  army,  special  forces,  combined,  joint,  etc.  For  this 
VBE,  this  tag  would  be  used  to  specify  “NAVY”  indicating  that  the  particular  military 
organisation  belongs  to  the  navy. 


<MIL_ORG_TYPE_TBL> 

<MIL_ORG_TYPE> 

<MI L_ORG_T YPE_I D>3805000000  < /MI L_ORG_T YPE_I D> 
<CAT_CODE>UNIT</CAT_CODE> 

<SERVICE_CODE>NAVY</SERVICE_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

< / M I L_ORG_T Y  PE > 

<MIL_ORG_TYPE> 

<MI L_ORG_TYPE_I D>3806000000  < /MI L_ORG_TYPE_I D> 

<CAT_CODE>UNI T< / CAT_CODE> 

<SERVICE_CODE>NAVY</SERVICE_CODE> 

<OWNER_I D> I < / OWNER_I D> 

<UPDATE_SEQNR>I</UPDATE_SEQNR> 

</MIL_ORG_TYPE> 

<MIL_ORG_TYPE> 

<MI L_ORG_TYPE_I D>3807000000  < /MI L_ORG_TYPE_I D> 
<CAT_CODE>UNIT</CAT_CODE> 

<SERVICE_CODE>NAVY</SERVICE_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</MIL_ORG_TYPE> 

<MIL_ORG_TYPE> 

<MIL_ORG_TYPE_I D>38080000  0  0</MIL_ORG_TYPE_I D> 

<CAT_CODE>UNI T< / CAT_CODE> 

<SERVICE_CODE>NAVY</SERVICE_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>I</UPDATE_SEQNR> 

< / M I L_ORG_T Y  PE > 

<MIL_ORG_TYPE> 

<MI L_ORG_TYPE_I D>3810000000  < /MI L_ORG_TYPE_I D> 
<CAT_CODE>MILPST</CAT_CODE> 

<SERVICE_CODE>NAVY</SERVICE_CODE> 

<OWNER_I D> I < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</MIL_ORG_TYPE> 

</MIL_ORG_TYPE_TBL> 

Figure  17.  The  military-organisation-type  table  is  the  only  table  in  the  incomplete  specialization  of 

the  government-organisation  structure. 
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4.1.14  Types  of  Units 


The  UNIT  TYPE  (unit-type)  table  (Figure  18)  is  defined  as  “A  MILITARY- 
ORGANISATION-TYPE  whose  structure  is  prescribed  by  competent  authority”  [13]. 
This  table  assists  in  the  specification  of  the  military -organisation-type  and  the 
equipment-type. 

The  <UNIT_TYPE_ID>  (Figure  18)  is  used  to  provide  a  link  back  to  the 
<MIL_ORG_TYPE_ID>  in  Figure  17.  Each  <CAT_CODE>  in  the  unit-type  table 
contains  “COMBAT”,  indicating  that  the  unit  is  capable  of  firepower  and  destructive 
force  in  the  battlespace.  The  <ARM_CAT_CODE>  indicates  the  specific  arm  or 
branch  of  the  unit  that  is  being  described.  Possible  arms  include  landing  support, 
medical  or  reconnaissance.  In  this  case,  the  arm  is  “NOS”  or  not  otherwise  specified. 

The  arm-specialization-code  <ARM_SPCLSN_CODE>  further  divides  the  arm  into 
specializations.  The  specializations  may  be  branches  such  as  dental,  motorised  or 
veterinary.  In  this  case,  the  <ARM_SPCLSN_CODE>  is  “NAVAL”  indicating  that  the 
unit  is  employed  in  the  naval  regime. 

The  size-code  (<SIZE_CODE>)  is  defined  as  “The  specific  value  that  represents  the 
relative  size  of  the  commonly  accepted  configuration  of  military  formations”  [13]. 

The  “TSKEL”  content  indicates  that  the  unit  is  organised  for  a  specific  task.  The 
majority  of  allowed  codes  for  <SIZE_CODE>  are  specific  to  the  army.  This  is  one 
area  in  the  LC2IEDM  where  improvements  could  be  made  to  encompass  naval  units. 

The  <PRINCIPAL_EQPT_TYPE_ID>  provides  a  link  to  the  <EQPT_TYPE_ID>  in 
the  equipment-type  table  (see  Figure  13).  The  first  record  in  Figure  18  indicates  that 
the  primary  equipment  of  unit  “3805000000”  has  <PRINCIPAL_EQPT_TYPE_ID> 
of  “3800000000”.  Referring  back  to  Figure  13,  we  see  that  <EQPT_TYPE_ID>  of 
“3800000000”  indicates  a  vessel.  Thus,  the  military  organisation  unit  identified  by 
unit-id  of  “3805000000”  has  a  vessel  as  its  primary  equipment. 

The  supported-military-organisation-type-id  represents  a  link  back  to  the 
MIL  ORG  TYPE  table  (Figure  17).  The  link  allows  specification  of  another  military 
organisation  that  is  supported  by  the  unit.  In  this  way,  multiple  units  may  support  a 
larger  structure  or  military  organisation. 
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<UNIT_TYPE_TBL> 

<UNIT_TYPE> 

<UNIT_TYPE_ID>3805000000</UNIT_TYPE_ID> 

<CAT_CODE>COMBAT</CAT_CODE> 

<ARM_CAT_CODE>NOS</ARM_CAT_CODE> 

<ARM_SPCLSN_CODE>NAVAL</ARM_SPCLSN_CODE> 

<SIZE_CODE>TSKEL</SIZE_CODE> 

<PRINCIPAL_EQPT_TYPE_ID>3800000000</PRINCIPAL_EQPT_TYPE_ID> 

<SUPPORTED_MIL_ORG_TYPE_ID></SUPPORTED_MIL_ORG_TYPE_ID> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</UNIT_TYPE> 

<UNIT_TYPE> 

<UNIT_TYPE_ID>3806000000</UNIT_TYPE_ID> 

<CAT_CODE>COMBAT</CAT_CODE> 

<ARM_CAT_CODE>NOS</ARM_CAT_CODE> 

<ARM_SPCLSN_CODE>NAVAL</ARM_SPCLSN_CODE> 

<SIZE_CODE>TSKEL</SIZE_CODE> 

<PRINCIPAL_EQPT_TYPE_ID>3801000000</PRINCIPAL_EQPT_TYPE_ID> 
<SUPPORTED_MIL_ORG_TYPE_ID></SUPPORTED_MIL_ORG_TYPE_ID> 
<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</UNIT_TYPE> 

<UNIT_TYPE> 

<UNIT_TYPE_ID>3807000000</UNIT_TYPE_ID> 

<CAT_CODE>COMBAT< / CAT_CODE> 

< ARM_C AT_CO  DE  >N0  S  < / ARM_C AT_CO DE > 

<ARM_SPCLSN_CODE>NAVAL</ARM_SPCLSN_CODE> 

<SIZE_CODE>TSKEL</SIZE_CODE> 

<PRINCIPAL_EQPT_TYPE_ID>3802000000</PRINCIPAL_EQPT_TYPE_ID> 
<SUPPORTED_MIL_ORG_TYPE_ID></SUPPORTED_MIL_ORG_TYPE_ID> 
<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</UNIT_TYPE> 

<UNIT_TYPE> 

<UNIT_TYPE_ID>3808000000</UNIT_TYPE_ID> 

<CAT_CODE>COMBAT</CAT_CODE> 

< ARM_C AT_CO  DE  >N0  S  < / ARM_C AT_CO DE > 
<ARM_SPCLSN_CODE>NAVAL</ARM_SPCLSN_CODE> 

<S I ZE_CODE>TSKEL< /SI ZE_CODE> 

<PRINCIPAL_EQPT_TYPE_ID>3803000000</PRINCIPAL_EQPT_TYPE_ID> 
<SUPPORTED_MIL_ORG_TYPE_ID></SUPPORTED_MIL_ORG_TYPE_ID> 
<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</UNIT_TYPE> 

</UNIT_TYPE_TBL> 

Figure  18.  The  unit-type  tabie  is  one  tabie  in  an  incomplete  specialization  of  the 

military-organisation-type. 
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4.1.15  Military  Posting 


The  MIL  POST  TYPE  (military-post-type)  table  identifies  the  duties  of  a  particular 
person.  For  VBE-B,  only  the  Coalition  Task  Force  (CTF)  Commander  is  identified. 
Note  that  the  <CAT_CODE>  of  “AUTCDR”  indicates  an  officer  in  charge  of  a  unit, 
post,  camp  or  operation.  The  <RANK_CODE>  of  “OF6”  indicates  an  officer  of  rank 
Brigadier.  The  allowed  content  of  <RANK_CODE>  needs  to  be  expanded  to  include 
naval  personnel. 


<MIL_POST_TYPE_TBL> 

<MIL_POST_TYPE> 

<MIL_POST_TYPE_ID>3810000000</MIL_POST_TYPE_ID> 

<CAT_CODE>AUTCDR</CAT_CODE> 

<  RANK_C  ODE>OF6</ RANK_C 0 DE  > 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</MIL_POST_TYPE> 

</MIL_POST_TYPE_TBL> 

Figure  19.  The  military-post-type  table  describes  a  set  of  duties  to  be  fulfilled  by  a  particular 

person. 


4.1.16  Reporting  Data 

The  RPTD  (reporting-data)  table  is  shown  in  Figure  20.  Each  record  in  the 
reporting-data  table  represents  a  single  report  and  may  be  considered  similar  to  a 
report  from  a  person  or  organisation.  The  information  in  this  table  is  used  to  join  or 
amalgamate  information  from  other  tables  within  the  model. 

The  reporting-data-id  (<RPTD_ID>)  is  a  numeric  identifier  that  provides  links  to 
other  identifiers.  The  accuracy-code  is  intended  to  provide  a  general  appraisal  of  the 
data  composing  the  report.  For  example,  the  domain  of  the  accuracy-code  includes 
confirmed  (1),  probably  (2),  possible  (3),  doubtful  (4),  improbable  (5),  and  truth  cannot 
be  judged  (6)  [13].  The  data  receiver  would  set  the  accuracy-code. 

The  category-code  is  described  as  “The  specific  value  that  represents,  for  usual 
operational  purposes,  the  nature  of  a  specific  REPORTING-DATA”  [13].  The  domain 
values  for  category-code  includes  assumed,  erroneous,  inferred,  planned,  reported  and 
restricted  [13]. 

The  <CNTG_IND_CODE>  or  counting-indicator-code  indicates  if  the  reported  data  is 
base  on  a  count  of  objects.  The  domain  is  Yes  and  No  [13]. 

The  credibility-code  (<CAT_CODE>)  provides  information  on  the  trustworthiness  of 
the  data  in  the  report.  Domain  values  include  indeterminate  (IND),  reported  as  a  fact 
(RPTFCT),  reported  as  plausible  (RPTPFA)  and  reported  as  uncertain  (RPTUNC).  In 
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Figure  20,  the  report  is  noted  to  be  “RPTFCT”,  or  reported  as  fact.  In  the 
documentation,  this  domain  value  has  a  definition  of  “Data  is  reported  by  different 
sources  whose  integrity  is  not  in  question”  [13]. 

Unfortunately  this  definition  includes  comment  on  the  integrity  of  the  source  and  not 
on  the  credibility  of  the  reported  data.  The  implication  is  that  source  integrity  implies 
credible  data.  However,  sources  can  be  completely  credible,  while  the  reported  data 
originating  from  the  source  is  not  credible.  The  distinction  is  easily  understood  by 
considering  the  justice  system,  which  places  considerable  emphasis  on  eyewitness 
accounts  of  criminal  activity.  In  1996,  the  American  Psychology  and  Law  Society 
examined  eyewitness  identification  of  criminals  and  subsequently  created  guidelines 
for  conducting  police  line-up  identifications.  The  case  study  [31]  examined  40 
conviction  cases  that  were  later  exonerated  using  DNA  evidence.  Of  the  40  cases,  36 
(90%)  used  eyewitness  identification  information  that  assisted  the  conviction. 

Another  problem  is  related  to  mixing  of  information  within  the  attributes  of  the  record. 
The  reliability-code  is  an  attribute  that  specifically  deals  with  the  source  integrity.  As 
such,  the  integrity  comment  in  the  RPTFCT  definition  should  not  be  present  in  the 
credibility-code  attribute,  but  rather  solely  contained  in  the  reliability-code. 


<RPTD_TBL> 

<RPTD> 

<RPTD_ID>4800000000</RPTD_ID> 

<ACCURACY_CODE>3</ACCURACY_CODE> 

<CAT_CODE>REP</CAT_CODE> 

<CNTG_IND_CODE>YES</CNTG_IND_CODE> 

<CREDIBILITY_CODE>RPTFCT</CREDIBILITY_CODE> 

<RELIABILITY_CODE>C</RELIABILITY_CODE> 

<  RE  P_D AT  E  >36517</RE  P_D AT  E  > 

<REP_TIME>54000</REP_TIME> 

<SOURCE_TYPE_CODE>UNSPEC</SOURCE_TYPE_CODE> 

<TIMING_CAT_CODE>RDABST</TIMING_CAT_CODE> 

<REF_ID>1800000000</REF_ID> 

<REP_ORG_I D>28100000  0  0< /REP_ORG_I D> 
<ENT_CAT_CODE>ACTEFF</ENT_CAT_CODE> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</RPTD> 

</RPTD_TBL> 

Figure  20.  The  reporting-data  table  identifies  reported  information.  Numerous  codes  help  specify 

the  information  contained  in  the  report. 


The  reliability-code  judges  the  reported  information  source  in  terms  of  the  likelihood 
that  the  source  provides  information  that  is  free  of  error.  The  domain  values  include 
completely  reliable  (A),  usually  reliable  (B),  fairly  reliable  (C),  not  usually  reliable 
(D),  reliability  cannot  be  judged  (F),  and  unreliable  (E)  [13]. 
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As  the  codes  used  within  reporting-data  are  assembled,  the  potential  for  confusion 
amongst  the  codes  becomes  evident.  Table  3  summarizes  a  potential  set  of  codes  to  be 
used  within  reporting-data.  The  codes  do  not  violate  any  reporting-data  business 
rules  yet  clearly  contradict  one  another.  For  example,  the  reported  data  is  based  on 
fact  or  observation  {category-code),  it  is  from  different  sources  {credibility-code),  the 
integrity  of  the  source  is  not  in  question  {credibility-code)  and  erroneous  information 
cannot  be  produced  {reliability-code),  yet  the  information  is  probably  erroneous 
{accuracy-code). 

The  attributes  shown  in  Table  3  indicate  a  data  dependency  termed  a  functional 
dependency  in  relational  database  theory.  A  functional  dependency  exists  between  the 
set  of  attributes  category-code,  credibility-code,  and  reliability-code,  and  the 
accuracy-code.  A  functional  dependency  [32,  33,  34]  occurs  when  the  value  in  one 
field  specifies  the  value  in  another  field.  In  this  case,  the  value  of  the  set  {category- 
code,  credibility-code,  reliability-code}  specifies  the  field  value  for  accuracy-code.  In 
the  Table  3  example,  the  values  in  the  set  would  result  in  an  accuracy-code  value  of 
“1”  indicating,  “confirmed”  or  “Reported  data  is  confirmed  by  at  least  3  independent 
sources”  [13]. 

To  avoid  potential  inconsistencies  in  the  database  as  a  result  of  this  type  of  functional 
dependency,  the  data  modeller  can  either  introduce  a  business  rule  to  remove  the 
possibility  of  data  such  as  that  shown  in  Table  3  from  being  entered  into  the  database, 
or  can  introduce  an  intersection  table^.  If  a  business  rule  is  added,  then  developed 
interfaces  to  the  database  must  ensure  the  proper  implementation  of  the  rule.  As  well, 
database  administrators  must  ensure  that  any  direct  database  manipulation  of  the  data 
is  consistent  with  the  business  rule.  An  intersection  table  is  the  preferred  solution  as 
this  avoids  the  coding  of  business  rules  and  maintains  the  content  restriction  to  the 
database  management  software  level,  which  then  applies  to  all  data  access  operations. 

The  reporting-date  and  reporting-time  (Figure  20)  fields  refer  to  the  date  and  time  of 
data  entry  into  the  database.  This  is  not  the  date  and  time  of  the  reported  data. 

The  source-type-code  refers  to  the  original  source  of  information.  The  data  in 
LC2IEDM  must  have  originated  from  some  other  source  of  information,  such  as  an 
email,  a  contact  or  human  intelligence.  This  code  specifies  the  source  type.  There  are 
at  present  23  source  type  codes. 


^  An  intersection  table  would  contain  all  valid  combinations  of  attribute  values.  The  data  shown  in 
Table  3  would  not  be  present  in  the  intersection  table  because  it  is  not  a  valid  combination  of  data. 
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Table  3.  Codes  are  used  extensively  within  the  reporting-data  table.  Some  code  values 

contradict  other  code  values  that  can  be  used  in  the  same  record.  For  example,  the 
codes  shown  below  are  valid  in  a  single  reporting-data  record,  but  are  contradictory. 


ATTRIBUTE 

CODE 

CODE  DESCRIPTION 

accuracy-code 

5 

Reported  data  shall  be  considered  as  probably  erroneous. 

category-code 

REP 

A  REPORTING-DATA  that  points  to  data  based  on  fact  or 
observation. 

credibility-code 

RPTFCT 

Data  is  reported  by  different  sources  whose  integrity  is  not  in 
question. 

reliability-code 

A 

The  source  of  the  reported  data  can  be  considered  as  completely 
reliable,  i.e.  erroneous  information  cannot  be  produced. 

The  timing-category-code  simply  indicates  if  the  time  of  the  reported  data  is  in 
absolute  or  relative  time.  An  example  of  an  absolute  time  would  be  a  time  at  a  specific 
hour,  month,  day,  etc.  An  example  of  a  relative  time  would  be  10  hours  after  a  defined 
absolute  time. 

The  reference-id  (<REF_ID>)  and  reporting-organisation-id  (<REP_ORG_ID>)  are 
numeric  identifiers  used  in  other  tables  in  the  LC2IEDM.  The  reference-id  is  used  in 
the  reference  table  (see  Figure  3)  and  links  the  reported  data  to  the  referenced 
information  source.  The  reporting-organisation-id  is  the  only  link  to  an  external 
object  as  defined  in  LC2IEDM. 

The  entity-category-code  (<ENT_CAT_CODE>,  note  that  this  is  the  assumed  logical 
name)  refers  to  the  physical  name  of  the  referenced  table.  The  definitions  associated 
with  entity-category-code  are  unclear  [14],  however,  progress  has  been  made  on 
understanding  this  field. 

The  entity-category-code  is  directly  related  to  the  only  business  rule  associated  with 
the  reporting-data  table.  The  business  rule  [12]  states  that  a  reporting-data  record 
may  only  refer  to  data  in  a  single  entity.  The  entity-category-code  describes  the  name 
of  the  entity  that  the  particular  reporting-data  record  references.  This  allows  the 
overlying  software  to  quickly  locate  the  data  being  referenced  by  the  reporting-data 
record. 


4.1.17  Timing  of  the  Reported  Data 

The  report  in  Figure  20  was  noted  to  have  an  identifier  of  “4800000000”.  A  similar 
identifier  in  the  <RPTD_ABS_TIMING_RPTD_ID>  (see  Figure  21)  provides  the  link 
between  the  two  records.  The  data  timing  is  then  specified  by  an  effective-date  and 
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effective-time  (e.g.,  <EFFCTV_DATE>).  Note  that  this  is  the  time  corresponding  to 
the  data. 

The  precision  of  the  time  value  is  indicated  by  the 

<EFFCTV_TIME_PRECISION_CODE>.  In  this  case  a  precision  of  “SECOND” 
indicates  that  the  time  value  is  known  to  the  nearest  second.  The  duration  time  for 
which  the  reported  information  applies,  is  specified  in  the  <DUR>  content. 

The  date  value  is  indicated  in  Figure  21  using  the  number  of  days  from  January  1, 
1970.  This  day  format  is  compliant  with  the  Version  4.0  Generic  Hub  documentation 
but  is  not  consistent  with  Version  5  LC2IEDM  documentation.  The  Version  5 
documentation  [12]  indicates  that  date  is  to  be  specified  as  yymmdd,  where  yy 
indicates  year,  mm  indicates  month  and  dd  indicates  day. 

The  time  (<EFFCTV_TIME>)  is  specified  in  seconds  for  the  indicated  day.  The 
format  for  time  is  hhmmss  where  hh  indicates  hours,  mm  indicates  minutes  and  ss 
indicates  seconds. 


<RPTD_ABS_TIMING_TBL> 

<RPTD_ABS_TIMING> 

<RPTD_ABS_TIMING_RPTD_ID>4800000000</RPTD_ABS_TIMING_RPTD_ID> 

<DUR>0</DUR> 

<EFFCTV_DATE>2452764</EFFCTV_DATE> 

<EFFCTV_TIME>54000</EFFCTV_TIME> 

<EFFCTV_TIME_PRECISION_CODE>SECOND</EFFCTV_TIME_PRECISION_CODE> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</RPTD_ABS_TIMING> 

</RPTD_ABS_TIMING_TBL> 

Figure  21.  The  reporting-data-absolute-timing  table.  This  table  stores  the  date  and  time 

applicable  to  the  reported  information. 


4. 1 . 1 8  T y pes  of  Objects 

The  OBJ  ITEM  TYPE  (object-item-type)  table  applies  a  link  between  the  particular 
object  item  and  the  object  type.  Recall  that  object  items  may  be  counted,  and  thus 
refer  to  specific  objects.  Object  types  are  classes  of  objects. 

The  records  for  object-item-type  are  shown  in  Figure  22.  The  <OBJ_ITEM_ID> 
provides  a  link  to  the  particular  object-item,  as  shown  in  Figure  4.  The  value  of 
“2800000000”  indicates  the  TeKaha  platform.  The  <OBJ_TYPE_ID>  of 
“3800000000”  indicates  a  Type45  platform  from  the  UK  (as  shown  in  Figure  10). 
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The  object-item-type-index  (<OBJ_ITEM_TYPE_IX>)  provides  a  counter  for  the 
reports  on  a  single  object  that  has  a  consistently  defined  type.  For  example,  in  a 
coalition  setting  multiple  platforms  may  report  on  a  single  object  item.  The  report  may 
be  from  different  sources,  with  varying  credibility,  but  indicate  the  same  typing  for  the 
object.  The  index  would  provide  the  ability  to  store  this  varied  information. 

The  link  to  reporting-data  is  provided  using  <RPTD_ID>.  The  link  provides 
considerable  information  as  outlined  in  Section  4.1.16.  For  example,  the  link  provides 
information  on  who  reported  the  typing  information,  the  credibility  of  the  report,  the 
date/time  of  the  reported  information,  etc. 


4.1.19  The  Status  of  Objects 

The  OBJ  ITEM  STAT  (object-item-status)  table  provides  information  on  the  current 
hostility  and  condition  of  the  object  item.  The  <OBJ_ITEM_ID>  provides  a  link  to  the 
object-item  table,  as  shown  in  Figure  4.  Thus,  the  first  record  given  in  Figure  23  is  for 
the  TeKaha  platform.  The  <OBJ_ITEM_STAT_IX>  provides  an  index  for  the 
evolution  of  the  objects  status.  The  <CAT_CODE>  indicates  the  category  of  the 
object,  and  should  agree  with  the  category  indicated  in  Figure  4  for  that  object. 

The  hostility-code  (<HSTLY_CODE>)  represents  the  perceived  hostility  of  the  object. 
For  the  TeKaha,  the  hostility  is  denoted  “APR”  which  indicates  assumed  friendly.  The 
booby-trap-indicator-code  indicates  if  the  object  has  been  booby  trapped. 

Note  that  the  object-item-status  also  contains  a  link  to  reporting-data  via  the 
<RPTD_ID>.  This  allows  reports  to  enter  the  database  that  change  the  status  of 
objects  (e.g.,  the  hostility  of  an  object).  This  also  allows  the  identification  of  the 
information  source  that  changed  the  object’s  status. 
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<OBJ_ITEM_TYPE_TBL> 

<OBJ_ITEM_TYPE> 

<0B J_I TEM_I D>2800000000  < /OB J_I TEM_I D> 

<OB J_TYPE_I D>38000000  0  0</OB J_TYPE_I D> 

<OBJ_ITEM_TYPE_IX>l</OBJ_ITEM_TYPE_IX> 

<RPTD_ID>4800000000</RPTD_ID> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM_TYPE> 

<OBJ_ITEM_TYPE> 

<OBJ_ITEM_ID>2801000000</OBJ_ITEM_ID> 

<OB J_TYPE_I D>38010000  0  0</OB J_TYPE_I D> 
<OBJ_ITEM_TYPE_IX>l</OBJ_ITEM_TYPE_IX> 

<RPTD_I D> 4800000000  < /RPTD_I D> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</OBJ_ITEM_TYPE> 

<OBJ_ITEM_TYPE> 

<OB J_I TEM_I D>2802000000  < /OB J_I TEM_I D> 
<OBJ_TYPE_ID>3802000000</OBJ_TYPE_ID> 
<OBJ_ITEM_TYPE_IX>l</OBJ_ITEM_TYPE_IX> 

<RPTD_I D> 4800000000  < /RPTD_I D> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM_TYPE> 

<OBJ_ITEM_TYPE> 

<OBJ_ITEM_ID>2803000000</OBJ_ITEM_ID> 

<OBJ_TYPE_ID>3803000000</OBJ_TYPE_ID> 

<OBJ_ITEM_TYPE_IX>l</OBJ_ITEM_TYPE_IX> 

<RPTD_ID>4800000000</RPTD_ID> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM_TYPE> 

</OBJ_ITEM_TYPE_TBL> 

Figure  22.  The  object-item-type  tabie  specifies  the  iink  between  a  particuiar  object-item  and  an 

object-type. 
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<OBJ_ITEM_STAT_TBL> 

<OBJ_ITEM_STAT> 

<0B J_I TEM_I D>2800000000  < /OB J_I TEM_I D> 
<OBJ_ITEM_STAT_IX>l</OBJ_ITEM_STAT_IX> 

<CAT_CODE>MA< / CAT_CODE> 

<HSTLY_CODE>AFR</HSTLY_CODE> 

<BOOBY_TRAP_IND_CODE>NO</BOOBY_TRAP_IND_CODE> 

<RPTD_I D> 4800000000  < /RPTD_I D> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM_STAT> 

<OBJ_ITEM_STAT> 

<OB J_I TEM_I D>2801000000  < /OB J_I TEM_I D> 
<OBJ_ITEM_STAT_IX>l</OBJ_ITEM_STAT_IX> 

<CAT_CODE>MA< / CAT_CODE> 

<HSTLY_CODE>AFR</HSTLY_CODE> 

<BOOBY_TRAP_IND_CODE>NO</BOOBY_TRAP_IND_CODE> 

<RPTD_I D> 4800000000  < /RPTD_I D> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

< / OB  J_I TEM_S  TAT> 

<OBJ_ITEM_STAT> 

<OB J_I TEM_I D>2802000000  < /OB J_I TEM_I D> 
<OBJ_ITEM_STAT_IX>l</OBJ_ITEM_STAT_IX> 

<CAT_CODE>MA< / CAT_CODE> 

<HSTLY_CODE>AFR</HSTLY_CODE> 

<BOOBY_TRAP_IND_CODE>NO</BOOBY_TRAP_IND_CODE> 

<RPTD_I D> 4800000000  < /RPTD_I D> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

< / OB  J_I TEM_S  TAT> 

<OBJ_ITEM_STAT> 

<OBJ_ITEM_ID>2803000000</OBJ_ITEM_ID> 

<OBJ_ITEM_STAT_IX>l</OBJ_ITEM_STAT_IX> 

<CAT_CODE>MA< / CAT_CODE> 

<HSTLY_CODE>AFR</HSTLY_CODE> 

<BOOBY_TRAP_IND_CODE>NO</BOOBY_TRAP_IND_CODE> 

<RPTD_I D> 4800000000  < /RPTD_I D> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</OBJ_ITEM_STAT> 

</OBJ_ITEM_STAT_TBL> 

Figure  23.  The  object-item-status  table  provides  information  on  the  hostility  level  of  the  object. 


It  may  be  useful  to  visualize  the  table  structure  used  thus  far  in  the  data  model.  This  is 
shown  in  Figure  24.  The  figure  shows  the  table  names  in  uppercase  characters  above 
the  table.  A  rectangular  box  illustrates  a  table.  Column  names  and  data  types  are 
indicted  within  the  table.  Primary  keys  are  indicated  as  named  columns  above  the 
horizontal  separator  line  in  the  table.  Below  the  separator  line  are  non-key  column 
names. 
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OBJ  ITEM  STAT 


objjtemjd:  NUMBER(15) 
obj item stat ix:  NUMBER(15) 


cat_code:  CHAR(6) 
hstly_code:  CHAR(6) 
booby_trapJnd_code:  CHAR(6) 
rptdjd:  NUMBER(18) 
ownerjd:  NUMBER(11) 
update_seqnr:  NUMBER(15) 


refjd:  NUMBER(15) 


format_code:  CHAR(6) 
descrjxt:  VARCHAR(255) 
security_clsfc_code:  CHAR(6) 
sourcejxt:  VARCHAR(255) 
trans_type_code:  CHAR(6) 
ownerjd:  NUMBER(11) 
update_seqnr:  NUMBER(15) 


rptdjd:  NUMBER(18) 

accuracy_code:  CHAR(6) 
cat_code:  CHAR(6) 
cntgJnd_code:  CHAR(6) 
credibility_code:  CHAR(6) 
reliability_code:  CHAR(6) 

_  rep_date:  CHAR(8) 
repjime:  CHAR(6) 
sourceJype_code:  CHAR(6) 
timing_cat_code:  CHAR(6) 
refjd:  NUMBER(15) 
rep_orgJd:  NUMBER(15) 
ent_cat_code:  CHAR(6) 
ownerjd:  NUMBER(11) 
update_seqnr:  NUMBER(15) 


RPTD_ABS_TIMING 
rptd_absjiming_rptdjd:  NUMBER(18) 

dur:  NUMBER(13,3) 
effctv_date:  CHAR(8) 
effctvjime:  CHAR(6) 
effctvJime_precision_code:  CHAR(6) 
ownerjd:  NUMBER(11) 
update_seqnr:  NUMBER(15) 


MAT _ 

''matjd:  NUMBER(15) 


serial_no_idJxt:  VARCHAR(50) 
lotjdentificjxt:  VARCHAR(IOO) 
body_colour_code:  CHAR(6) 
marking_code:  CHAR(6) 
marking_colour_code:  CHAR(6) 
ownerjd:  NUMBER(11) 
update_seqnr:  NUMBER(15) 


objjtemjd:  NUMBER(15) 

cat_code:  CHAR(6) 

-  name:  VARCHAR(IOO) 
altnjdentificjxt:  VARCHAR(255) 
ownerjd:  NUMBER(11) 
update_seqnr:  NUMBER(15) 


objjypejd:  NUMBER(15) 


matjypejd:  NUMBER(15) 


cat_code:  CHAR(6) 
dummyJnd_code:  CHAR(6) 
name:  VARCHAR(IOO) 
nationality_code:  CHAR(6) 
ownerjd:  NUMBER(11) 
update_seqnr:  NUMBER(15) 


cat_code:  CHAR(6) 
rptbljtemjxt:  VARCHAR(6) 
-m  stock_noJxt:  VARCHAR(15) 
supply_class_code:  CHAR(6) 
ownerjd:  NUMBER(11) 
update_seqnr:  NUMBER(15) 


EQPT  TYPE 


9RG  MAT  ASSOC _ 

"subj_orgJd:  NUMBER(15) 
obj_matJd:  NUMBER(15) 
org mat assocJx:  NUMBER(15) 


OBJ  ITEM  TYPE 

f objjtemjd:  NUMBER(15) 
objjypejd:  NUMBER(15) 
objjtemjypejx:  NUMBER(15) 

'  rptdjd:  NUMBER(18) 

ownerjd:  NUMBER(11) 
update_seqnr:  NUMBER(15) 


cat_code:  CHAR(6) 
ownerjd:  NUMBER(11) 
update_seqnr:  NUMBER(15) 


eqptjypejd:  NUMBER(15) 


cat_code:  CHAR(6) 
loaded_wt_qty:  NUMBER(12,3) 
unloaded_wt_qty:  NUMBER(12,3) 
max_height_dim:  NUMBER(12,3) 
maxjength_dim:  NUMBER(12,3) 
max_width_dim:  NUMBER(12,3) 
ownerjd:  NUMBER(11) 
update_seqnr:  NUMBER(15) 


j  orgjd:  NUMBER(15) 

cat_code:  CHAR(6) 
nickname_name:  VARCHAR(IOO) 
ownerjd:  NUMBER(11) 
update_seqnr:  NUMBER(15) 


VESSEL_TYPE  _ 

"vessel JypeJd:  NUMBER(15) 


cat_code:  CHAR(6) 
subcat_code:  CHAR(6) 
ownerjd:  NUMBER(11) 
update_seqnr:  NUMBER(15) 


unitjd:  NUMBER(15) 
formal_abbrd_name:  VARCHAR(IOO) 
ownerjd:  NUMBER(11) 
update_seqnr:  NUMBER(15) 


MIL_POST_TYPE 
"^mil_postJypeJd:  NUMBER(15) 

cat_code:  CHAR(6) 
rank_code:  CHAR(6) 
ownerjd:  NUMBER(11) 
update_seqnr:  NUMBER(15) 


GOVT_ORG_TYPE 
"govt_orgJypeJd:  NUMBER(15) 

’  cat_code:  CHAR(6) 

main_activity_code:  CHAR(6) 
ownerjd:  NUMBER(11) 
update_seqnr:  NUMBER(15) 


MIL  ORG  TYPE _ 

"mlLorgJypeJd:  NUMBER(15) 
cat_code:  CHAR(6) 
service_code:  CHAR(6) 
ownerjd:  NUMBER(11) 
update_seqnr:  NUMBER(15) 


ACFT_TYPE  _ 

"acftjypejd:  NUMBER(15) 


orgjypejd:  NUMBER(15) 

cat_code:  CHAR(6) 
descrjxt:  VARCHAR(50) 
ownerjd:  NUMBER(11) 
update_seqnr:  NUMBER(15) 


cat_code:  CHAR(6) 
subcat_code:  CHAR(6) 
ownerjd:  NUMBER(11) 
update_seqnr:  NUMBER(15) 


j  unitjypejd:  NUMBER(15) 


cat_code:  CHAR(6) 

•  arm_cat_code:  CHAR(6) 
arm_spclsn_code:  CHAR(6) 

^  size_code:  CHAR(6) 

"  ownerjd:  NUMBER(11) 
update_seqnr:  NUMBER(15) 
principal_eqptjypejd:  NUMBER(15) 

I  supported_mil_orgJype_id:  NUMBER(15) 


Figure  24.  The  LC2IEDM  Version  5.0  table  structure  used  thus  far  in  the  data  load.  The  colours 

(in  the  electronic  version)  may  be  ignored  (on  a  black  and  white  printed  page,  colour  may 
be  indicated  by  a  dotted  line).  The  rounded  edge  tables  indicate  dependent  tables,  while 
square  edges  indicate  independent  tables.  Relationships  are  indicated  using  IDEF1X 
notation  [35]. 


Relationships  are  illustrated  using  the  Integration  Definition  for  Information  Modelling 
(IDEFIX)  notation  [35].  This  notation  illustrates  a  relationship  between  tables  as 
either  a  solid  or  dashed  line.  The  solid  line  represents  a  relationship  where  the  foreign 
key  is  part  of  the  primary  key  in  the  child  table  (an  identifying  relationship).  A  dashed 
line  represents  a  relationship  where  the  foreign  key  is  not  part  of  the  primary  key  in  the 
child  table  (a  non-identifying  relationship).  A  solid  black  circle  on  the  end  of  a  line 
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indicates  zero,  one  or  more  records.  A  diamond  symbol  on  the  end  of  a  line  indicates 
zero  or  one  records.  No  symbol  on  the  end  of  a  line  indicates  one  record.  Finally,  a 
red  line  and  dot  indicates  a  specialization. 

Figure  24  illustrates  the  complicated  relationships  that  exist  within  the  small  number  of 
tables  used  thus  far.  Note  that  there  are  in  total  about  196  tables  in  the  LC2IEDM.  By 
understanding  the  relationships,  one  can  better  understand  the  load  sequence  presented 
in  the  previous  figures.  For  example,  a  table  with  relationships  indicated  with  circles 
(e.g.,  unit-type)  must  be  filled  after  the  parent  tables  at  the  other  end  of  the  relationship 
(e.g.,  equipment-type  and  military-organisation-type).  As  noted  previously,  the 
relationships  in  the  LC2IEDM  are  enforced  by  the  database,  not  by  OCXS.  Thus,  the 
XML  content  must  not  violate  any  of  these  relationships  or  the  database  will  issue  an 
error  that  will  manifest  itself  as  an  exception"^  from  OCXS. 


4.2  Initial  Load  -  Red  Force  Data 

Upon  entering  the  area  of  operation,  the  coalition  force  has  available  certain  red  force 
information.  For  example,  the  coalition  knows  there  are  hostile  frigates  in  the  area  of 
operation.  This  information  can  be  loaded  into  the  database  as  part  of  the  initial  load. 
The  following  section  will  describe  the  XML  load  for  the  information  known  at  the 
beginning  of  the  VBE. 


4.2.1  Red  Force  Objects 

The  known  red  force  objects  in  the  area  of  operation  are  described  in  Figure  25.  The 
figure  indicates  two  materiel  objects,  named  FFGl  and  FFG2.  The  <CAT_CODE> 
indicates  that  these  objects  are  “MA”  meaning  materiel.  As  such,  the  objects  are 
further  specified  in  Figure  26  in  the  materiel  table.  Both  objects  are  noted  to  be 
“GREY”  with  no  markings. 


4 


An  exception  is  an  error  condition  that  changes  the  normal  flow  of  control  in  a  software  program. 
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<OBJ_ITEM_TBL> 

<OBJ_ITEM> 

<0B  J_I TEM_I D>1801000000</OBJ_I TEM_I D> 

<CAT_CODE>MA</CAT_CODE> 

<NAME>FFG1</NAME> 

<ALTN_IDENTIFIC_TXT>FFG1</ALTN_IDENTIFIC_TXT> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM> 

<OBJ_ITEM> 

<OBJ_ITEM_ID>1801000001</OBJ_ITEM_ID> 

<CAT_CODE>MA</CAT_CODE> 

<NAME>FFG2</NAME> 

<ALTN_IDENTIFIC_TXT>FFG2</ALTN_IDENTIFIC_TXT> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</OBJ_ITEM> 

</OBJ_ITEM_TBL> 

Figure  25.  The  red  force  object  items  are  described  using  additionai  records  in  the  object-item 

tabie.  These  records  define  two  objects,  both  being  FFGs. 


<MAT_TBL> 

<MAT> 

<MAT_ID>1801000000</MAT_ID> 

<SERIAL_N0_ID_TXT>FFG-1</SERIAL_N0_ID_TXT> 

<LOT_I DENT I F I C_TXT>< / LOT_I DENT I F I C_TXT> 
<BODY_COLOUR_CODE>GREY</BODY_COLOUR_CODE> 
<MARKING_CODE>NOS</MARKING_CODE> 
<MARKING_COLOUR_CODE>NOS</MARKING_COLOUR_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</MAT> 

<MAT> 

<MAT_ID>1801000001</MAT_ID> 

<SERIAL_N0_ID_TXT>FFG-2</SERIAL_N0_ID_TXT> 

<LOT_I DENT I FI C_TXT>< / LOT_I DENT I FI C_TXT> 
<BODY_COLOUR_CODE>GREY</BODY_COLOUR_CODE> 
<MARKING_CODE>NOS</MARKING_CODE> 
<MARKING_COLOUR_CODE>NOS</MARKING_COLOUR_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</MAT> 

</MAT_TBL> 

Figure  26.  The  materiei  tabie  further  specifies  the  red  force  objects.  At  the  time  of  the  initiai  toad, 

the  oniy  known  information  on  the  red  force  objects  is  the  coiour  of  the  piatforms,  that 
being  grey. 
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4.2.2  The  Hostile  Object  Types 


The  object-type  table  indicates  the  class  of  the  hostile  platforms.  The  VBE 
experimental  plan  [8]  indicates  that  hostile  FFGs  are  in  the  area  of  operation  and  as 
such  the  data  load  assumes  that  there  is  one  type  of  hostile  platform.  This  is  indicated 
by  the  single  record  in  Figure  27.  The  figure  indicates  that  the  object  is  a  materiel,  as 
indicated  by  <CAT_CODE>  of  “MA”.  The  name  of  the  materiel  is  denoted 
“FRIGATE”  and  the  nationality  code  of  “OR”  indicates  “orange”.  Orange  is  a 
hypothetical  LC2IEDM  country  specification  that  is  used  in  war  games  [13]. 


<OBJ_TYPE_TBL> 

<OBJ_TYPE> 

<OB J_TYPE_I D>19010000  0  0< /OB J_TYPE_I D> 

<CAT_CODE>MA</CAT_CODE> 

<DUMMY_IND_CODE>NO</DUMMY_IND_CODE> 

<NAME>FRIGATE</NAME> 

<NAT I ONAL I T Y_CODE>OR< /NAT I ONAL I T Y_CODE> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_TYPE> 

</OBJ_TYPE_TBL> 

Figure  27.  The  object-type  table  record  for  the  hostile  platforms.  The  object-type  is  similar  to  the 

class  of  the  object.  Both  hostile  frigates  are  noted  to  be  the  same  type. 


4.2.3  Hostile  Materiel,  Equipment  and  Vessel  Types 

The  object-type  in  Figure  27  indicates  the  object  is  a  materiel  (see  <CAT_CODE  of 
“MA”).  To  further  specify  the  materiel,  the  specialization  table  materiel-type  is  used. 
Further  specializations  for  equipment-type  and  vessel-type  are  also  included,  and  are  all 
shown  in  Figure  28. 

Figure  28  shows  the  records  for  the  materiel-type,  equipment-type  and  vessel-type  for 
the  hostile  platforms.  Since  both  platforms  are  a  single  frigate  class,  only  one  record  is 
used  to  describe  the  characteristics  of  the  class.  The  materiel-type  record  indicates  that 
the  materiel  is  in  fact  equipment.  The  equipment-type  record  further  expands  this  to 
show  the  equipment  has  category  code  of  “VESSEL”.  The  weight  and  dimensions  of 
the  vessel  are  also  given. 

The  vessel-type  table  details  the  vessel.  Here,  it  is  noted  to  be  a  surface  frigate  by  the 
<CAT_CODE>  of  “SURFAC”  and  the  <SUBCAT_CODE>  of  “FRIGAT”. 
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<MAT_TYPE_TBL> 

<MAT_TYPE> 

<MAT_T YPE_I D> 1901000000  < /MAT_T YPE_I D> 

<CAT_CODE>EQ</CAT_CODE> 

<RPTBL_ITEM_TXT></RPTBL_ITEM_TXT> 

<STOCK_NO_TXT></STOCK_NO_TXT> 

<SUPPLY_CLASS_CODE></SUPPLY_CLASS_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</MAT_TYPE> 

</MAT_TYPE_TBL> 

<EQPT_TYPE_TBL> 

<EQPT_TYPE> 

<EQPT_T YPE_I D> 1901000000  < /EQPT_T YPE_I D> 
<CAT_CODE>VESSEL</CAT_CODE> 

<LOADED_WT_QTY>2  5  0  0  0  0  0  < / LOADED_WT_QTY> 
<UNLOADED_WT_QTY>0</UNLOADED_WT_QTY> 

<MAX_HE I GHT_D IM>  4  5  < /MAX_HE I GHT_D IM> 

<MAX_LENGTH_DIM>125</MAX_LENGTH_DIM> 

<MAX_WIDTH_DIM>15</MAX_WIDTH_DIM> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</EQPT_TYPE> 

</EQPT_TYPE_TBL> 

<VESSEL_TYPE_TBL> 

<VESSEL_TYPE> 

<VESSEL_TYPE_ID>1901000000</VESSEL_TYPE_ID> 

<CAT_CODE>SURFAC</CAT_CODE> 

<SUBCAT_CODE>FRIGAT</SUBCAT_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</VESSEL_TYPE> 

</VESSEL_TYPE_TBL> 

Figure  28.  The  materiel-type,  equipment-type  and  vessel-type  tables  further  describe  the  hostile 

platforms. 


4.2.4  The  Hostile  Objects 

The  hostile  object  items  are  now  linked  to  the  object  types  using  the  object-item-type 
table  as  shown  in  Figure  29.  The  <OBJ_ITEM_ID>  indicates  the  frigates  in  Figure  25 
while  the  single  object  type  is  described  in  Figure  27.  Again,  the  reporting-data-id 
(Figure  29)  is  linked  to  the  reporting-data  table  (Figure  20)  to  allow  the  typing  to  be 
linked  to  a  specific  report  on  the  object. 
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<OBJ_ITEM_TYPE_TBL> 

<OBJ_ITEM_TYPE> 

<0B  J_I TEM_I D>1801000000</OBJ_I TEM_I D> 

<0B J_TYPE_I D>19010000  0  0</OB J_TYPE_I D> 

<0BJ_ITEM_TYPE_IX>1</0BJ_ITEM_TYPE_IX> 

<RPTD_ID>4800000000</RPTD_ID> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM_TYPE> 

<OBJ_ITEM_TYPE> 

<OBJ_ITEM_ID>1801000001</OBJ_ITEM_ID> 

<0B J_TYPE_I D>19010000  0  0</OB J_TYPE_I D> 
<0BJ_ITEM_TYPE_IX>1</0BJ_ITEM_TYPE_IX> 

<RPTD_I D> 4800000000  < /RPTD_I D> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</OBJ_ITEM_TYPE> 

</OBJ_ITEM_TYPE_TBL> 

Figure  29.  The  hostile  object  items  and  object  type  are  linked  in  the  object-item-type  table. 


4.2.5  The  Status  of  Hostile  Objects 

The  status  of  the  hostile  objects  is  described  in  the  object-item-status  table  as  shown  in 
Figure  30.  Each  object  item  is  shown  to  be  a  materiel,  with  hostility  code  “HO” 
indicating  hostile.  Neither  hostile  object  is  thought  to  be  booby  trapped,  as  indicated 
by  the  “NO”  content  in  <BOOBY_TRAP_IND_CODE>. 
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<OBJ_ITEM_STAT_TBL> 

<OBJ_ITEM_STAT> 

<0B  J_I TEM_I D>1801000000</OBJ_I TEM_I D> 
<0BJ_ITEM_STAT_IX>1</0BJ_ITEM_STAT_IX> 

<CAT_CODE>MA< / CAT_CODE> 

<HSTLY_CODE>HO</HSTLY_CODE> 

<BOOBY_TRAP_IND_CODE>NO</BOOBY_TRAP_IND_CODE> 

<RPTD_I D> 4800000000  < /RPTD_I D> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM_STAT> 

<OBJ_ITEM_STAT> 

<OB  J_I TEM_I D>1801000001</OBJ_I TEM_I D> 
<OBJ_ITEM_STAT_IX>l</OBJ_ITEM_STAT_IX> 

<CAT_CODE>MA< / CAT_CODE> 

<HSTLY_CODE>HO</HSTLY_CODE> 

<BOOBY_TRAP_IND_CODE>NO</BOOBY_TRAP_IND_CODE> 

<RPTD_I D> 4800000000  < /RPTD_I D> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

< / OB  J_I TEM_S  TAT> 

</OBJ_ITEM_STAT_TBL> 

Figure  30.  The  object-item-status  tabie  is  used  to  describe  the  hostiiity  ievei  of  the  red  force 

objects. 


4.2.6  Using  Context 

A  small  section  of  the  context  load  is  shown  in  Figure  3 1  (full  load  shown  in  Annex  1). 
This  context  section  shows  a  context  record  that  identifies  a  surface  radar.  This 
equipment  will  be  linked  to  a  report  in  a  later  section  of  the  XML. 


<CONTXT> 

<CONTXT_ID>6800005000</CONTXT_ID> 

<NAME>Surf ace  Search  Radar</NAME> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</CONTXT> 

Figure  31.  A  small  part  of  the  context  table.  One  record  is  shown  that  will  be  used  in  the  Solution 

Report.  The  full  context  load  is  shown  in  Annex  1. 
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4.3  Initial  Load  -  Neutrals 


The  initial  load  of  the  neutrals  follows  the  load  sequence  for  the  hostile  units.  The 
XML  content  for  the  neutrals  is  shown  in  Annex  1  (see  section  of  Annex  1  marked 
with  the  comment  <!—  Start  Neutral  Description  — >). 

Annex  1  indicates  that  the  neutral  object  types  are  described  and  are  noted  to  be 
materiel.  Then,  the  materiel-type  is  used  to  indicate  that  the  materiel  may  be 
considered  equipment.  The  equipment  is  further  refined  to  be  a  vessel.  The  vessel- 
type  table  indicates  two  types,  a  fishing  vessel  and  a  merchant  vessel. 


4.4  Loading  a  Discovered  Contact 

The  XML  data  loads  thus  far  have  all  dealt  with  preliminary  information  available  to 
the  task  force  prior  to  entering  the  area  of  operation.  After  entering  the  area  of 
operation,  the  individual  platforms  can  detect  objects  in  their  area  of  detection,  and 
report  these  objects  to  a  shared  information  location.  The  LC2IEDM  acts  as  the  shared 
information  repository. 

The  VBE  plan  [8]  indicated  that  coalition  ships  have  radar  capabilities,  while  the 
ownship  submarine  (Sheean)  has  radar  and  electronic  support  measures  (ESM) 
available.  As  an  example  of  a  discovered  platform,  consider  the  TeKaha  platform 
discovering  a  contact. 

In  the  VBE  environment,  a  discovery  is  made  by  a  federate.  In  this  example,  we 
consider  a  radar  contact.  Radar  contacts  are  “discovered”  by  the  radar  federate. 

Having  made  the  discovery,  the  radar  federate  then  reports  the  discovered  contact  to 
the  High  Level  Architecture  (HLA)  Runtime  Infrastructure  (RTI)  (see  Figure  32).  The 
RTI  then  informs  the  OCXS  Gateway  Federate  of  the  new  contact.  The  OCXS 
Gateway  federate  then  generates  the  XML  messages  that  describe  the  contact.  These 
messages  are  then  sent  to  the  OCXS  application  server.  The  application  server  places 
the  content  into  the  LC2IEDM.  The  application  server  also  informs  Horizon  of  the 
additional  contact.  Horizon  is  the  software  environment  that  manages  the  track  data 
and  displays  the  tracks  to  an  operator  [9]. 

An  example  of  an  object  discovery  and  the  developed  XML  report  is  given  in  this 
section.  The  example  is  built  from  the  coalition  platform  TeKaha  discovering  the 
merchant  ship  known  as  Merchantb. 
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Figure  32.  The  radar  federate  discovers  the  contact  and  informs  the  RTI.  The  RTI  passes  the 

data  to  the  OCXS  Gateway  federate,  which  generates  the  XML  and  passes  this  to  the 
OCXS  Application  Server.  The  Application  Server  places  the  data  into  the  LC2IEDM.  The 
Application  Server  also  sends  the  XML  message  to  the  Horizon  OCXS  plugin.  This 
informs  Horizon  of  the  new  contact. 


4.4.1  The  Contact  Report 

The  knowledge  of  the  contact  is  based  on  a  report  that  is  placed  into  the  reporting-data 
table.  The  report  is  shown  in  Figure  33.  This  shows  the  report  originates  from 
reporting-organisation-id  of  “2805000000”.  This  organisation  is  noted  to  be  the  FFH2 
Command,  as  noted  by  Figure  5.  As  well,  the  command  is  known  to  exist  on  the 
platform  with  <OBJ_ITEM_ID>  of  “2800000000”  as  indicated  by  the  organisation- 
materiel-association  shown  in  Figure  9.  This  object-item  is  actually  the  TeKaha  as 
indicted  in  Figure  4. 

It  should  also  be  noted  that  OCXS  has  hard-coded  the  entity-category-code  to 
“ACTEFF”  [36].  The  business  rule  for  the  reporting-data  table  indicates  that  the 
correct  content  in  this  case  would  be  “OILOCA”  representing  the  object-item-location 
record  to  be  shown  later  in  the  XML  (Figure  35).  More  discussion  regarding  the 
reporting-data  business  rule  will  follow  in  Section  4.4.4. 
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<?xml  version= ' 1 . 0 '  ?> 

<GH5Complete  xmlns : dt="urn : schemas-microsof t-com : datatypes"> 
<RPTD_TBL> 

<RPTD> 

<RPTD_ID>-2147467264</RPTD_ID> 

<ACCURACY_C0DE>3</ACCURACY_C0DE> 

<CAT_CODE>REP</CAT_CODE> 

<CNTG_IND_CODE>YES</CNTG_IND_CODE> 

<CREDIBILITY_CODE>RPTFCT</CREDIBILITY_CODE> 

<RELIABILITY_CODE>C</RELIABILITY_CODE> 

<RE  P_DATE>  0  0037579</RE  P_DATE> 

<REP_TIME>062214</REP_TIME> 

<SOURCE_TYPE_CODE>VARI</SOURCE_TYPE_CODE> 

<TIMING_CAT_CODE>RDABST</TIMING_CAT_CODE> 

<REF_ID>1800000000</REF_ID> 

<REP_ORG_ID>2805000000</REP_ORG_ID> 

<ENT_CAT_CODE>ACTEFF</ENT_CAT_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</RPTD> 

</RPTD_TBL> 

<RPTD_ABS_TIMING_TBL> 

<RPTD_ABS_TIMING> 

<RPTD_ABS_TIMING_RPTD_ID>-2147467264</RPTD_ABS_TIMING_RPTD_ID> 

<DUR>0</DUR> 

<EFFCTV_DATE>00037579</EFFCTV_DATE> 

<EFFCTV_TIME>0  622  0  9</EFFCTV_TIME> 

<EFFCTV_TIME_PRECISION_CODE>SECOND</EFFCTV_TIME_PRECISION_CODE> 
<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</RPTD_ABS_TIMING> 

</RPTD_ABS_TIMING_TBL> 

Figure  33.  The  contact  report  takes  the  form  of  a  record  in  the  reporting-data  tabie. 


4.4.2  The  Positional  Information 

To  locate  an  object  in  space,  the  LC2IEDM  must  first  have  a  position  defined.  Only 
after  a  position  is  defined,  can  an  object  be  associated  with  that  position.  The  first 
object  to  be  positioned  by  the  reported  information  is  the  reporting  platform,  the 
TeKaha. 

To  define  a  position  or  location  in  space,  the  LC2IEDM  requires  the  LOG  {location) 
table  be  filled  with  a  unique  identifier  for  the  location.  This  is  shown  in  Figure  34. 

The  location  given  in  Figure  34  indicates  a  point  location  via  the  <CAT_CODE>  of 
“PT”.  This  location  is  then  expanded  via  the  POINT  {point)  table.  The  link  is  obtained 
between  the  two  tables  via  the  <LOC  ID>  and  the  <POINT  ID>. 
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The  “ABS”  <CAT_CODE>  in  the  point  table  indicates  the  type  of  point,  in  this  case  an 
absolute-point. 


<LOC_TBL> 

<LOC> 

<LOC_ID>-2147467263</LOC_ID> 

<CAT_CODE>PT</CAT_CODE> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</LOC> 

</LOC_TBL> 

<POINT_TBL> 

<POINT> 

<POINT_ID>-2147467263</POINT_ID> 

<CAT_CODE>ABS</CAT_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</POINT> 

</POINT_TBL> 

<VER_DIST_TBL> 

<VER_DIST> 

<VER_DIST_ID>-2147467263</VER_DIST_ID> 

<CAT_CODE>LOCSUR</CAT_CODE> 

<DIM>0</DIM> 

<PRECISION_CODE>10M</PRECISION_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</VER_DIST> 

</VER_DIST_TBL> 

<ABS_POINT_TBL> 

<ABS_POINT> 

<ABS_POINT_ID>-2147467263</ABS_POINT_ID> 

<LAT_COORD>34 . 2</LAT_COORD> 

<LONG_COORD>93 . 2</LONG_COORD> 

<ANGULAR_PREC I S ION_CODE>SECOND< / ANGULAR_PREC I S ION_CODE> 

<AB  S_PO INT_VER_D IST_ID>-2147467263</AB  S_PO INT_VER_D I S  T_I D> 
<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</ABS_POINT> 

</ABS_POINT_TBL> 

Figure  34.  The  location  of  a  point  is  defined,  with  the  point  being  an  absolute  point  at  a  specific 

latitude  and  longitude.  The  point  is  also  noted  to  be  at  the  sea  surface. 


The  absolute-point  table  is  then  used  to  define  the  actual  spatial  coordinates  of  the 
point.  However,  before  filling  the  absolute-point  table,  the  VER_D1ST 
(vertical-distance)  table  must  be  filled.  The  vertical-distance  table  indicates  via  the 
<CAT_CODE>  that  the  vertical  describes  the  “LOCSUR”  or  location  surface.  This 
content  is  set  by  the  OCXS  Java  class  OcxsSolution  [36]. 


54 


DRDC  Atlantic  TM  2004-002 


The  <DIM>  field  indicates  the  vertical  dimension,  which  in  this  case  is  0  m.  Note  that 
version  5.0  of  the  LC2IEDM  defined  the  vertical  distance  as  only  positive,  while 
version  6.0  should  allow  negative  values  in  the  dimension  field.  In  this  case,  the  0  m 
dimension  indicates  a  platform  operating  at  sea  level. 

The  ABS_POINT  {absolute-point)  table  then  links  to  the  point  and  vertical-distance 
table.  The  link  to  point  is  obtained  via  the  <ABS_POINT_ID>  while  the  link  to  the 
vertical-distance  table  is  obtained  through  the  <ABS_POINT_VER_DIST_ID>  field. 
In  the  present  case,  both  of  these  XML  elements  contain  the  same  content.  The 
<PRECISION_CODE>  in  the  absolute-point  table  indicates  that  the  position  is  known 
to  within  one  second  of  arc. 


4.4.3  Linking  TeKaha  to  a  Position 

The  position  of  the  TeKaha  object  is  determined  by  relating  the  object  to  a  location  in 
space.  In  this  case,  the  location  was  defined  by  the  XML  shown  in  Figure  34. 

The  object-item-location  table  is  used  to  relate  the  object  item  and  the  location,  as 
shown  in  Figure  35.  The  TeKaha  is  noted  by  the  <OBJ_ITEM_ID>  of  “2800000000” 
(see  Figure  4)  and  is  linked  to  a  location  by  the  <LOC_ID>  of  “-2 147467263”  (see 
Figure  34).  The  TeKaha  is  noted  to  be  on  a  course  of  27 1 .5°  (noted  by 
<BEARING_ANGLE>),  and  travelling  at  a  speed  of  5.6  km/hr,  or  about  3.0  knots. 
Note  that  the  <RPTD_ID>  has  a  value  of  “-2147467264”.  This  report  was  shown  in 
Figure  33.  Again,  the  report  allows  one  to  identify  the  source  and  validity  of 
information,  as  well  as  the  date  and  time  associated  with  the  report. 


<OBJ_ITEM_LOC_TBL> 

<OBJ_ITEM_LOC> 

<LOC_ID>-2147467263</LOC_ID> 

<OBJ_ITEM_ID>2800000000</OBJ_ITEM_ID> 

<OBJ_ITEM_LOC_IX>l</OBJ_ITEM_LOC_IX> 

<ACCURACY_QTY></ACCURACY_QTY> 

<BEARING_ANGLE>271 . 5</BEARING_ANGLE> 

<SPEED_RATE>5 . 6</SPEED_RATE> 

<GEOMETRY_CFEAT_TYPE_ID></GEOMETRY_CFEAT_TYPE_ID> 

<RPTD_ID>-2147467264</RPTD_ID> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM_LOC> 

</OBJ_ITEM_LOC_TBL> 

Figure  35.  The  link  is  established  between  the  TeKaha  object  and  the  location  point. 
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4.4.4  The  Report 


The  second  report  in  the  XML  message  describes  the  reported  information  that 
pertains  to  Merchantb.  The  report,  shown  in  Figure  36,  indicates  an  accuracy  of  “3”, 
which  indicates  that  the  reported  information  is  “Possible”  [13]  and  only  from  one 
source.  The  data  in  the  report  is  based  on  facts,  as  indicated  by  the  <CAT_CODE>  of 
“REP”.  The  credibility-code  indicates  that  the  report  is  based  on  fact,  and  is  reported 
by  different  sources.  The  reliability-code  indicates  that  the  source  is  “fairly  reliable”. 

The  reporting-data-date  and  reporting-data-time  are  the  date/time  of  the  insertion  into 
the  database.  The  date  is  indicated  by  the  number  of  days  since  January  1,  1970.  This 
form  follows  the  format  for  GH  Version  4.0  (see  Section  4.1.16.). 

The  source-type-code  in  the  report  indicates  the  type  of  source  from  which  the 
information  was  obtained.  In  this  report,  the  information  is  based  on  a  contact  and  is 
indicated  by  “CONTAC”.  The  timing-category-code  indicates  that  the  reported  data 
time  is  absolute. 

One  problem  with  the  OCXS  report  is  related  to  the  number  of  tables  being  referred  to 
by  the  single  reporting-data  record.  The  business  rule  applicable  to  the  reporting-data 
table  specifies  that  a  single  reporting-data  record  should  be  used  to  refer  to  data  in  a 
single  entity  only  [12].  The  Solution  Report  load  from  OCXS  violates  this  business 
rule,  by  loading  records  into  many  tables  rather  than  only  one  table  per  reporting-data 
record.  This  Solution  Report  loads  the  tables  object-item-type,  object-item-status  and 
object-item-location.  There  should  be  one  reporting-data  record  for  each  of  the 
records  in  these  tables.  Then,  the  entity-category-code  for  each  of  the  reporting-data 
records  would  specify  the  particular  table  where  the  other  insert  has  taken  place. 
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<RPTD_TBL> 

<RPTD> 

<RPTD_ID>-2147467262</RPTD_ID> 

<ACCURACY_C0DE>3</ACCURACY_C0DE> 

<CAT_CODE>REP</CAT_CODE> 

<CNTG_IND_CODE>YES</CNTG_IND_CODE> 

<CREDIBILITY_CODE>RPTFCT</CREDIBILITY_CODE> 

<RELIABILITY_CODE>C</RELIABILITY_CODE> 

<RE  P_DATE>  0  0037579</RE  P_DATE> 

<REP_TIME>062214</REP_TIME> 

<SOURCE_TYPE_CODE>CONTAC</SOURCE_TYPE_CODE> 

<TIMING_CAT_CODE>RDABST</TIMING_CAT_CODE> 

<REF_ID>1800000000</REF_ID> 

<REP_ORG_ID>2805000000</REP_ORG_ID> 

<ENT_CAT_CODE>ACTEFF</ENT_CAT_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</RPTD> 

</RPTD_TBL> 

<RPTD_ABS_TIMING_TBL> 

<RPTD_ABS_TIMING> 

<RPTD_ABS_TIMING_RPTD_ID>-2147467262</RPTD_ABS_TIMING_RPTD_ID> 

<DUR>0</DUR> 

<EFFCTV_DATE>00 03757 9</EFFCTV_DATE> 

<EFFCTV_TIME>0  622  0  9</EFFCTV_TIME> 

<EFFCTV_TIME_PRECISION_CODE>SECOND</EFFCTV_TIME_PRECISION_CODE> 
<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</RPTD_ABS_TIMING> 

</RPTD_ABS_TIMING_TBL> 

Figure  36.  The  reporting-data  record  indicates  that  a  contact  has  been  obtained.  The  information 

reiated  to  the  report  quaiity  characteristics  are  indicated  in  this  record.  The 
reporting-data-absoiute-timing  table  indicates  the  time  of  the  contact. 


The  reporting  organisation  is  indicated  with  <REP_ORG_ID>  and  has  a  value  of 
“2805000000”.  This  ID  is  related  back  to  Figure  8  that  indicates  that  the  reporting 
unit  is  “FFH2”.  Using  Figure  9  and  Figure  4,  we  can  determine  that  the  reporting 
platform  is  the  TeKaha. 

The  reporting-data-absolute-timing-effective-date  and  effective-time  (also  shown  in 
Figure  36)  indicates  the  time  pertaining  to  the  reported  information,  not  the  time  of 
data  insertion  into  the  database.  Again,  the  date/time  format  follows  Version  4.0  of  the 
GH. 
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4.4.5  The  Merchant  6  Object 


As  a  newly  discovered  object,  Merchantb  needs  to  be  identified  as  an  item  within 
LC2IEDM.  This  is  accomplished  via  the  object-item  table,  as  shown  in  Figure  37. 

The  record  indicates  the  name  of  the  object  as 

“TeKaha_Radar_01_Merchant6_2:2”.  This  name  could  be  simply  “Merchantb”. 
The  alternate-identification-text  in  Figure  37  is  also  used  to  identify  the  fact  that  this  is 
the  eighth  real  world  object  identified  in  the  experiment  (recall  there  are  two  fishing 
vessels  and  six  merchant  vessels  in  the  experiment). 

The  materiel  table  can  also  be  used  to  further  describe  the  discovered  object 
(e.g.,  colour  and  markings).  In  the  case  of  a  radar  contact,  such  information  is  not 
available. 


<OBJ_ITEM_TBL> 

<OBJ_ITEM> 

<OBJ_ITEM_ID>-2147467259</OBJ_ITEM_ID> 

<CAT_CODE>MA< / CAT_CODE> 

<NAME>TeKaha_Radar_01_Mer chant 6_2 : 2</NAME> 

<ALTN_IDENTIFIC_TXT>vRealWorldContact_8</ALTN_IDENTIFIC_TXT> 
<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</OBJ_ITEM> 

</OBJ_ITEM_TBL> 

<MAT_TBL> 

<MAT> 

<MAT_ID>-2147467259</MAT_ID> 

<SERIAL_NO_ID_TXT></SERIAL_NO_ID_TXT> 

<LOT_IDENTIFIC_TXT></LOT_IDENTIFIC_TXT> 

<BODY_COLOUR_CODE>NOS</BODY_COLOUR_CODE> 

<MARKING_CODE>NOS</MARKING_CODE> 

<MARKING_COLOUR_CODE>NOS</MARKING_COLOUR_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</MAT> 

</MAT_TBL> 

Figure  37.  The  Merchants  object  must  be  defined  as  an  object  within  the  LC2IEDM.  The 

object-item  table  is  used  to  define  the  physical  object. 


4.4.6  The  Merchant  6  Type 

The  Merchantb  object  was  defined  in  Figure  37,  but  defining  the  object  does  not 
describe  the  object.  The  object  is  described  using  the  object-item-type  table  as  shown 
in  Figure  38. 
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The  object-item-type  is  linked  to  the  object-type  table  content  shown  in  Annex  1  (see 
section  on  neutrals).  The  XML  content  in  Annex  1  describes  a  Merchant  vessel  of 
New  Zealand  nationality.  The  object-item- type  table  links  the  object  to  the  type, 
thereby  establishing  the  relation  between  the  object  named 
“TeKaha_Radar_01_Merchant6_2:2”  and  the  Merchant  class  of  vessel. 

The  status  of  the  object  is  also  described  in  Figure  38.  The  status,  which  is  primarily 
for  reporting  the  hostility  level  of  the  object,  is  reported  as  “AFR”,  or  assumed  friendly. 
Note  that  the  <RPTD_ID>  indicates  the  report  from  Figure  36.  This  linkage  provides 
the  source  that  reported  the  information. 


<OBJ_ITEM_TYPE_TBL> 

<OBJ_ITEM_TYPE> 

<OBJ_ITEM_ID>-2147467259</OBJ_ITEM_ID> 

<OB  J_T YPE_I D>1901020000</OB  J_T YPE_I D> 

<OBJ_ITEM_TYPE_IX>l</OBJ_ITEM_TYPE_IX> 

<RPTD_ID>-2147467262</RPTD_ID> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</OBJ_ITEM_TYPE> 

</OBJ_ITEM_TYPE_TBL> 

<OBJ_ITEM_STAT_TBL> 

<OBJ_ITEM_STAT> 

<OBJ_ITEM_ID>-2147467259</OBJ_ITEM_ID> 

<OBJ_ITEM_STAT_IX>l</OBJ_ITEM_STAT_IX> 

<CAT_CODE>MA</CAT_CODE> 

<HSTLY_CODE>AFR</HSTLY_CODE> 

<BOOBY_TRAP_IND_CODE>NO</BOOBY_TRAP_IND_CODE> 

<RPTD_ID>-2147467262</RPTD_ID> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM_STAT> 

</OBJ_ITEM_STAT_TBL> 

Figure  38.  The  object-item-type  estabiishes  the  reiationship  between  the  object  named  Merchants 

and  the  type  of  object.  The  type  of  object  was  described  in  the  initiai  ioad.  See  Annex  1  in 
the  section  for  neutrais. 


4AJ  Defining  an  Elliptical  Area  of  Uncertainty 

The  radar  detection  of  Merchant6  is  based  on  a  radar  contact.  In  this  case,  the  contact 
will  be  described  using  an  elliptical  area  of  uncertainty.  To  describe  the  position  in 
this  way,  the  radar  report  must  contain  the  necessary  content  to  create  the  elliptical 
area  in  the  LC2IEDM  database. 

The  LC2IEDM  elliptical  definition  is  based  on  three  points  and  a  surface.  The  points 
define  the  centre  of  the  ellipse,  and  the  intersection  of  the  major  and  minor  axis  with 
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the  ellipse.  The  intersection  points  are  known  as  the  first  and  second  conjugate  points 
of  the  ellipse  (see  Figure  39). 


Figure  39.  The  elliptical  shape  is  described  using  three  points:  the  centre,  and  two  points  on  the 

elliptical  surface  at  the  semi-major  and  semi-minor  axes  [12]. 


The  elliptical  area  is  defined  using  three  points  associated  with  the  elliptical  shape.  To 
define  the  ellipse,  the  radar  report  first  defines  the  centre  of  the  ellipse.  This  location 
is  defined  by  the  XML  tags  as  shown  in  Figure  40. 

The  <LOC_ID>  shown  in  Figure  40  has  an  associated  absolute-point-id  that  indicates 
a  point  at  35.5°N  and  95.5°E.  The  vertical-distance  table  indicates  a  <CAT_CODE> 
of  “LOCSUR”  meaning  “The  datum  for  VERTICAL-DISTANCE  provided  by  terrain 
or  sea  level  at  a  point  or  area”  [13].  The  precision-code  indicates  we  know  the  vertical 
position  to  within  10  m.  This  point  will  be  used  as  the  centre  point  of  the  elliptical 
area  of  uncertainty.  The  point,  vertical-distance  and  absolute-point  data  is  defined 
similarly  to  Figure  34. 
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<LOC_TBL> 

<LOC> 

<LOC_ID>-2147467260</LOC_ID> 

<CAT_CODE>PT</CAT_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</LOC> 

</LOC_TBL> 

<POINT_TBL> 

<POINT> 

<POINT_ID>-2147467260</POINT_ID> 

<CAT_CODE>ABS</CAT_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</POINT> 

</POINT_TBL> 

<VER_DIST_TBL> 

<VER_DIST> 

<VER_DIST_ID>-2147467260</VER_DIST_ID> 

<CAT_CODE>LOCSUR</CAT_CODE> 

<DIM>0</DIM> 

<PRECISION_CODE>10M</PRECISION_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</VER_DIST> 

</VER_DIST_TBL> 

<ABS_POINT_TBL> 

<ABS_POINT> 

<ABS_POINT_ID>-2147467260</ABS_POINT_ID> 

<LAT_COORD>35 . 5</LAT_C00RD> 

<LONG_COORD>95 . 5</L0NG_C00RD> 

<ANGULAR_PREC I S ION_CODE>SECOND< / ANGULAR_PREC I S ION_CODE> 

<AB  S_PO I NT_VER_D IST_ID>-2147467260  < / ABS_PO I NT_VER_D I S  T_I D> 
<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</ABS_POINT> 

</ABS_POINT_TBL> 

Figure  40.  The  first  position  is  described  for  what  wilt  be  defined  as  the  centre  point  of  the 

elliptical  area  of  uncertainty.  This  will  be  used  to  locate  the  radar  contact  for  the 
Merchants  vessel. 


Next,  we  define  three  additional  locations:  two  points  and  a  surface  as  shown  in 
Figure  41 .  The  points  are  located  on  the  elliptical  surface  and  thus  will  be  used  as  the 
first  and  second  conjugate  points.  In  Figure  41,  the  points  are  indicated  by  the 
<CAT_CODE>  of  “PT”  while  the  surface  is  indicated  by  “SURFAC”. 
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<LOC_TBL> 

<LOC> 

<LOC_ID>-2147467258</LOC_ID> 

<CAT_CODE>PT</CAT_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</LOC> 

<LOC> 

<LOC_ID>-2147467257</LOC_ID> 

<CAT_CODE>PT</CAT_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</LOC> 

<LOC> 

<LOC_ID>-2147467256</LOC_ID> 

<CAT_CODE>SURFAC</CAT_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</LOC> 

</LOC_TBL> 

Figure  41.  The  location  table  defines  two  additional  points  and  a  surface.  These  will  be  used  to 

describe  an  elliptical  surface. 


The  two  points  are  described  in  Figure  42.  The  vertical  distance  of  these  two  points  is 
noted  to  be  zero  metres  in  the  vertical-distance  table.  This  indicates  that  the  points  are 
on  the  sea  surface.  The  two  points  are  noted  to  be  absolute,  by  the  <CAT_CODE>  in 
the  point  records  (see  Figure  42).  The  absolute-point  table  (Figure  43)  then  describes 
the  two  points  as  being  located  at  35.6°N,  95.5°W  and  35.5°N,  98.5°W. 
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<POINT_TBL> 

<POINT> 

<POINT_ID>-2147467258</POINT_ID> 

<CAT_CODE>ABS</CAT_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</POINT> 

<POINT> 

<POINT_ID>-2147467257</POINT_ID> 

<CAT_CODE>ABS</CAT_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</POINT> 

</POINT_TBL> 

<VER_DIST_TBL> 

<VER_DIST> 

<VER_DIST_ID>-2147467258</VER_DIST_ID> 

<CAT_CODE>LOCSUR</CAT_CODE> 

<DIM>0</DIM> 

<PRECISION_CODE>10M</PRECISION_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</VER_DIST> 

<VER_DIST> 

<VER_DIST_ID>-2147467257</VER_DIST_ID> 

<CAT_CODE>LOCSUR</CAT_CODE> 

<DIM>0</DIM> 

<PRECISION_CODE>10M</PRECISION_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR> 1 < /UPDATE_SEQNR> 

</VER_DIST> 

</VER_DIST_TBL> 

Figure  42.  The  two  points  for  the  eiiipticai  surface  are  described  using  the  point  tabie.  The 

verticai-distance  tabie  describes  the  verticai  position  of  the  two  points.  Both  points  are  at 
the  sea  surface. 
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<ABS_POINT_TBL> 

<ABS_POINT> 

<ABS_POINT_ID>-2147467258</ABS_POINT_ID> 

<LAT_COORD>35 . 6</LAT_C00RD> 

<LONG_COORD>95 . 5</L0NG_C00RD> 

<ANGULAR_PREC I S ION_CODE>SECOND< / ANGULAR_PREC I S ION_CODE> 

<AB  S_PO I NT_VER_D IST_ID>-2147467258</AB  S_PO I NT_VER_D I S  T_I D> 
<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</ABS_POINT> 

<ABS_POINT> 

<ABS_POINT_ID>-2147467257</ABS_POINT_ID> 

<LAT_COORD>35 . 5</LAT_C00RD> 

<LONG_COORD>98 . 5</L0NG_C00RD> 

<ANGULAR_PREC I S ION_CODE>SECOND< / ANGULAR_PREC I S ION_CODE> 
<ABS_POINT_VER_DIST_ID>-2147467257</ABS_POINT_VER_DIST_ID> 
<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</ABS_POINT> 

</ABS_POINT_TBL> 

Figure  43.  The  absolute-point  table  is  used  to  describe  two  points  in  latitude-longitude  space. 

These  points  will  be  used  to  define  the  elliptical  surface  for  the  Merchants  contact. 


The  surface  of  the  area  of  uncertainty  is  then  defined  using  the  SURTACE  (surface) 
table  as  shown  in  Figure  44.  The  surface  <CAT_CODE>  indicates  that  the  defined 
surface  is  an  ellipse.  The  <SUREACE_1D>  refers  back  to  the  <LOC_ID>  from 
Figure  41. 


<SURFACE_TBL> 

<SURFACE> 

<SURFACE_ID>-2147467256</SURFACE_ID> 

<CAT_CODE>ELLPSE</CAT_CODE> 

<OWNER_I D> 1 < / OWNER_I D> 
<UPDATE_SEQNR>1</UPDATE_SEQNR> 
</SURFACE> 

</SURFACE_TBL> 

Figure  44.  The  surface  table  defines  an  elliptical  surface. 


The  ellipse  is  described  as  in  Figure  45.  The  centre  point  of  the  ellipse  is  noted  to  be 
point  “-21 47467260”.  Recall  that  this  point  is  located  at  35.5°N,  95.5°W  as  indicated 
by  Figure  40.  The  first  conjugate  axis  is  noted  to  be  point  “-21 47467258”  while  the 
second  conjugate  point  has  ID  “-2 147467257” . 
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<ELPS_TBL> 

<ELPS> 

<ELPS_ID>-2147467256</ELPS_ID> 

<ELPS_CENTRE_POINT_ID>-2147467260</ELPS_CENTRE_POINT_ID> 
<ELPS_FIRST_CNJG_DIAM_POINT_ID>-21474 67258 
</ELPS_FIRST_CNJG_DIAM_POINT_ID> 

<ELPS_SCND_CNJG_DIAM_POINT_ID>-2147467257 

</ELPS_SCND_CNJG_DIAM_POINT_ID> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</ELPS> 

</ELPS_TBL> 

Figure  45.  The  elliptical  shape  is  described  in  the  ellipse  table.  The  record  refers  to  the  three 

points  used  to  define  the  ellipse. 


4.4.8  Positioning  Merchant  6  in  the  Area  of  Uncertainty 

The  final  step  is  to  associate  the  ellipse  with  the  object.  This  is  completed  using  the 
object-item-location  table  as  shown  in  Figure  46.  The  <L0C_1D>  of  “-2147467256“ 
relates  to  the  <L0C_1D>  in  Figure  41,  which  in  turn  links  to  the  <SURFACE_1D>  in 
Figure  44.  This  table  is  also  used  to  describe  the  present  bearing  and  speed  of  the 
object,  in  this  case  Merchantb.  The  speed  value  of  12.34  km/hr  corresponds  to  6.66 
knots. 


<OBJ_ITEM_LOC_TBL> 

<OBJ_ITEM_LOC> 

<LOC_ID>-2147467256</LOC_ID> 

<OBJ_ITEM_ID>-2147467259</OBJ_ITEM_ID> 

<0BJ_ITEM_L0C_IX>1</0BJ_ITEM_L0C_IX> 

<ACCURACY_QTY></ACCURACY_QTY> 

<BEARING_ANGLE>45 . 6</BEARING_ANGLE> 

<SPEED_RATE>12 . 34</SPEED_RATE> 

<GEOMETRY_CFEAT_TYPE_ID></GEOMETRY_CFEAT_TYPE_ID> 

<RPTD_ID>-2147467262</RPTD_ID> 

<OWNER_I D> 1 < / OWNER_I D> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM_LOC> 

</OBJ_ITEM_LOC_TBL> 

</GH5Complete> 

Figure  46.  The  object  item  for  the  Merchants  vessel  is  linked  to  the  location-id  corresponding  to 

the  elliptical  surface.  The  bearing  and  speed  of  the  object  is  also  given. 
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4.4.9  Placing  it  in  Context 


The  final  part  of  the  Solution  Report  is  the  context  (Figure  47).  The  present  usage  of 
the  context  table  relates  a  reporting-data  record  to  a  context  record  (see  Figure  31) 
established  in  the  initial  load.  Figure  47  establishes  the  link  between  the  context-id  and 
the  reporting-data-id.  The  intent  of  this  link  is  to  indicate  that  the  reporting-data 
information  was  obtained  via  a  surface  radar,  as  indicated  by  the  context  table  in 
Figure  31. 


<CONTXT_RPTD_ASSOC_TBL> 

<CONTXT_RPTD_ASSOC> 

<CONTXT_ID>6800005000</CONTXT_ID> 

<RPTD_ID>-2147467262</RPTD_ID> 

<CONTXT_RPTD_ASSOC_IX>l</CONTXT_RPTD_ASSOC_IX> 

<CAT_CODE>ISDFT</CAT_CODE> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</CONTXT_RPTD_ASSOC> 

</CONTXT_RPTD_ASSOC_TBL> 

Figure  47.  The  context  and  reporting-data  relationship  is  established  via  the 

context-reporting-data-association  table. 
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5.  Concluding  Remarks 


This  report  has  documented  the  details  of  the  data  load  into  the  LC2IEDM  during 
VBE-B.  Although  the  content  of  the  data  load  is  specific  to  VBE-B,  the  procedure 
followed  and  the  type  of  data  loaded  applies  to  many  naval  tracking  operations,  not 
just  a  Virtual  Battle  Experiment. 

During  the  writing  of  this  report,  considerable  knowledge  was  gained  by  the  authors  on 
an  assortment  of  topics.  By  actually  placing  data  into  the  LC2IEDM,  we  further 
familiarized  ourselves  with  the  details  of  the  entities  and  relationships  within  the  data 
model.  However,  the  report  has  highlighted  many  inconsistencies  and  possible 
inadequacies  in  the  components  used  during  the  data  load.  These  issues  may  be 
grouped  into  three  categories:  the  LC2IEDM  data  model,  the  LC2IEDM 
documentation  and  the  OCXS  software  package. 

Based  on  the  authors’  current  level  of  understanding,  several  recommendations  are 
provided  that  would  alleviate  problems  with  the  data  model.  For  example: 

•  Multiple  codes  in  a  single  record  often  leads  to  inappropriate  code 
combinations.  The  combination  of  codes  in  the  record,  which  can  be 
considered  a  concatenation  of  codes,  may  not  represent  something  that  is 
consistent. 

An  example  of  this  problem  is  present  in  the  reporting-data  record.  Code 
combinations  can  exist  which  do  not  provide  consistent  information  (see 
Table  3).  Creating  business  rules  or  possibly  table  restructuring  to  include  an 
intersection  table  can  reduce  this  problem.  Both  the  business  rule  and 
intersection  table  would  act  to  restrict  the  code  to  reasonable  combinations  in 
the  reporting-data  table. 

•  Within  the  LC2IEDM  there  often  appears  to  be  multiple  solutions  to  a  single 
data  entry  problem.  In  other  words,  a  single  set  of  data  can  rationally  be 
placed  in  different  tables  or  groups  of  tables.  This  problem  is  similar  to 
organising  a  filing  cabinet,  where  a  file  labelled  “Mission  Orders”  may 
rationally  be  filed  under  “M”  for  Mission  or  “O”  for  Orders.  An  example 
within  the  LC2IEDM  is  the  use  of  context  to  group  objects,  and  the  possible 
use  of  organisation  or  holdings  to  perform  the  same  function. 

This  investigation  has  also  highlighted  potential  problems  with  the  LC2IEDM 
documentation.  In  some  cases,  the  LC2IEDM  documentation  should  be  critically 
examined  and  clarified.  The  following  issues  were  noted  during  this  investigation. 

•  There  are  many  examples  where  the  code  intent  and  the  definition  of  a 
particular  code  value  appear  to  diverge.  To  fully  understand  this,  one  needs  to 
recognise  the  subtle  differences  between  the  field,  the  code,  and  the 
corresponding  field  and  code  definitions.  As  the  container,  the  field  is  labelled 
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with  a  name  that  is  related  to  the  field  definition.  The  field  definition  provides 
a  description  of  the  functional  purpose  of  the  field,  (i.e.  what  the  field  should 
be  used  for).  The  code  represents  the  content  for  the  field,  and  is  typically  an 
abbreviated  set  of  characters  that  represent  an  agreed  upon  definition.  A 
problem  develops  when  the  code  definition  does  not  correspond  to  the  field 
definition.  In  these  cases,  the  code  may  be  used  to  store  information  not 
originally  intended  as  per  the  field  definition. 

As  an  example  of  this,  consider  the  table  reporting-data  and  the  field 
credibility-code.  The  credibility-code  is  intended  to  store  a  statement  on  the 
trustworthiness  of  the  reported  data.  However,  a  possible  code  for  this  field  is 
“RPTFCT”  which  indicates  the  data  is  “reported  by  different  sources  whose 
integrity  is  not  in  question”  [13].  There  are  two  problems  within  this  example. 
First,  the  field,  as  indicated  by  the  definition,  is  not  intended  to  store 
information  on  the  number  of  sources.  Second,  the  field  is  not  intended  to 
store  information  on  the  integrity  of  the  sources.  Indeed,  the  integrity  of  the 
source  is  contained  in  a  separate  field. 

Although  some  may  consider  this  to  be  a  minor  point,  in  any  interoperable 
solution  it  is  critically  important  that  all  parties  know  where  to  find  the 
required  information.  Any  conflicts  in  definitions  leave  open  the  possibility  of 
information  confusion. 

•  As  the  LC2IEDM  moves  toward  joint  use,  many  code  lists  will  need  to  include 
the  naval  perspective.  This  applies  to  various  code  lists  utilized  during  this 
investigation  (e.g.  unit-type-size-code  and  military-post-type-rank-code). 


The  Operational  Context  Exchange  Service  (OCXS)  was  utilized  in  this  investigation. 
OCXS  is  the  software  package  that  provides  an  interface  from  outside  applications  to 
the  LC2IEDM  structure.  The  OCXS  needs  to  evolve,  and  in  particular  the  following 
issues  need  to  be  addressed: 

•  OCXS  needs  to  accommodate  the  next  official  version  of  LC2IEDM. 
Considerable  changes  have  taken  place  since  version  5,  which  is  currently  the 
LC2IEDM  supported  by  OCXS.  By  remaining  current,  OCXS  may  also  be 
able  to  influence  the  evolution  of  the  data  model,  and  thereby  better  meet  the 
needs  of  the  navy. 

•  OCXS  needs  to  implement  the  business  rules  in  the  model  specification.  In 
particular,  the  business  rule  associated  with  reporting-data  should  be 
implemented.  This  would  provide  researchers  with  a  more  accurate 
representation  of  information  storage  within  the  LC2IEDM. 

•  OCXS  documentation  needs  to  be  developed.  Documentation  is  essential  for 
any  software  package  that  provides  a  service  to  users  with  a  wide  range  of 
abilities.  Efforts  are  underway  to  develop  the  required  documentation  [36], 
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but  a  more  focused  effort  would  expedite  the  process  and  improve  the  overall 
product. 


As  we  look  toward  future  VBE  scenarios,  a  wealth  of  opportunity  exists  for  exercising 
the  LC2IEDM.  The  experiments  provide  an  excellent  forum  for  the  naval  assessment 
of  the  data  model,  and  as  the  experiments  move  toward  more  realistic  simulations 
other  aspects  of  the  model  can  be  exercised.  For  example,  the  VBEs  could  use  the 
planning  section  of  the  model  for  mission  orders  or  platform  tasking.  In  this  case,  the 
experiment  could  investigate  not  only  the  technical  aspect  of  data  sharing,  but  also  the 
human  aspect,  such  as  operator  responses  to  varied  mission  planning  by  another 
platform. 

As  TTCP  MAR  TP  -  1  moves  forward  with  VBE  investigations,  researchers  hope  to 
continue  the  collaborative  investigations  on  naval  information  sharing.  This  research 
will  focus  on  the  details  of  what  information  is  shared  and  on  the  mechanics  of  how  the 
information  is  shared.  Only  by  understanding  both  aspects,  will  researchers  be  able  to 
contribute  to  naval  information  solutions  in  a  networked  environment. 
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Annex  1 :  Initial  XML  Load  for  VBE-B 


<?xinl  version=  '  1 . 0  '  ?> 

<GH5Coinplete  xmlns : dt="urn : schemas-microsoft-com: datatypes"> 

<REF_TBL> 

<REF> 

<REF_ID>1800000000</REF_ID> 

<FORMAT_CODE>NOS</FORMAT_CODE> 

<DESCR_TXT>MAR  TP-1  VBE-B  OCXS  Data  Fill</DESCR_TXT> 
<SECURITY_CLSFC_CODE>NU</SECURITY_CLSFC_CODE> 
<SOURCE_TXT>Scenario  1 . xml</SOURCE_TXT> 
<TRANS_TYPE_CODE>EMLMSG</TRANS_TYPE_CODE> 
<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</REF> 

</REF_TBL> 

<OBJ_ITEM_TBL> 

<OBJ_ITEM> 

<OBJ_ITEM_ID>2800000000</OBJ_ITEM_ID> 

<CAT_CODE>MA</CAT_CODE> 

<NAME>TeKaha</NAME> 

<ALTN_IDENTIFIC_TXT></ALTN_IDENTIFIC_TXT> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM> 

<OBJ_ITEM> 

<OBJ_ITEM_ID>2801000000</OBJ_ITEM_ID> 

<  C AT_CO  DE  >MA< / C AT_CO DE  > 

<NAME>Sheean</NAME> 

<ALTN_IDENTIFIC_TXT></ALTN_IDENTIFIC_TXT> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM> 

<OBJ_ITEM> 

<OBJ_ITEM_ID>2802000000</OBJ_ITEM_ID> 

<  C AT_CO  DE  >MA< / C AT_CO DE  > 

<NAME >UAV< /NAME > 

<ALTN_IDENTIFIC_TXT></ALTN_IDENTIFIC_TXT> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM> 

<OBJ_ITEM> 

<OBJ_ITEM_ID>2803000000</OBJ_ITEM_ID> 

< C AT_C 0 DE >MA< / C AT_C 0 DE > 

<NAME>Halifax</NAME> 

<ALTN_IDENTIFIC_TXT></ALTN_IDENTIFIC_TXT> 

<OWNER  ID>1</0WNER  ID> 
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<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM> 

<OBJ_ITEM> 

<OBJ_ITEM_ID>2805000000</OBJ_ITEM_ID> 

<CAT_CODE>OR</CAT_CODE> 

<NAME>FFH2  Coinmand</NAME> 

<ALTN_IDENTIFIC_TXT></ALTN_IDENTIFIC_TXT> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM> 

<OBJ_ITEM> 

<OBJ_ITEM_ID>2806000000</OBJ_ITEM_ID> 

<CAT_CODE>OR</CAT_CODE> 

<NAME>Sheean  Coinmand</NAME> 
<ALTN_IDENTIFIC_TXT></ALTN_IDENTIFIC_TXT> 
<0WNER_ID>1</0WNER_ID> 
<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM> 

<OBJ_ITEM> 

<OBJ_ITEM_ID>2807000000</OBJ_ITEM_ID> 

<CAT_CODE>OR</CAT_CODE> 

<NAME>UAV  Coinmand</NAME> 

<ALTN_IDENTIFIC_TXT></ALTN_IDENTIFIC_TXT> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM> 

<OBJ_ITEM> 

<OBJ_ITEM_ID>2808000000</OBJ_ITEM_ID> 

<CAT_CODE>OR</CAT_CODE> 

<NAME>FFH1  Coinmand</NAME> 

<ALTN_IDENTIFIC_TXT></ALTN_IDENTIFIC_TXT> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM> 

<OBJ_ITEM> 

<OBJ_ITEM_ID>2810000000</OBJ_ITEM_ID> 

<CAT_CODE>OR</CAT_CODE> 

<NAME>TP-1  Coalition  Coinmander</NAME> 
<ALTN_IDENTIFIC_TXT></ALTN_IDENTIFIC_TXT> 
<0WNER_ID>1</0WNER_ID> 
<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM> 

</OBJ_ITEM_TBL> 

<MAT_TBL> 

<MAT> 

<MAT_I D>2 8 0 0 0 0 0 0 0 0 < /MAT_I D> 

<SERIAL_NO_ID_TXT></SERIAL_NO_ID_TXT> 

<LOT_IDENTIFIC_TXT></LOT_IDENTIFIC_TXT> 

<BODY_COLOUR_CODE>GREY</BODY_COLOUR_CODE> 

<MARKING_CODE>NOS</MARKING_CODE> 

<MARKING_COLOUR_CODE>NOS</MARKING_COLOUR_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE  SEQNR>1</UPDATE  SEQNR> 
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</MAT> 

<MAT> 

<MAT_I D>2 8 0 1 0 0 0 0 0 0 < /MAT_I D> 

<SERIAL_NO_ID_TXT></SERIAL_NO_ID_TXT> 

<LOT_IDENTIFIC_TXT></LOT_IDENTIFIC_TXT> 

<BODY_COLOUR_CODE>BLACK</BODY_COLOUR_CODE> 

<MARK I NG_C ODE>NOS</ MARK I NG_C 0 DE  > 

<MARKING_COLOUR_CODE>NOS</MARKING_COLOUR_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</MAT> 

<MAT> 

<MAT_I D>2802000000< /MAT_I D> 

<SERIAL_NO_ID_TXT></SERIAL_NO_ID_TXT> 

<LOT_IDENTIFIC_TXT></LOT_IDENTIFIC_TXT> 

<BODY_COLOUR_CODE>WHITE</BODY_COLOUR_CODE> 

<MARK I NG_C ODE>NOS</ MARK I NG_C 0 DE  > 

<MARKING_COLOUR_CODE>NOS</MARKING_COLOUR_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</MAT> 

<MAT> 

<MAT_I D>2 8 0 3 0 0 0 0 0 0 < /MAT_I D> 
<SERIAL_NO_ID_TXT></SERIAL_NO_ID_TXT> 
<LOT_IDENTIFIC_TXT></LOT_IDENTIFIC_TXT> 
<BODY_COLOUR_CODE>GREY</BODY_COLOUR_CODE> 

<MARK I NG_C ODE>NOS</ MARK I NG_C 0 DE  > 
<MARKING_COLOUR_CODE>NOS</MARKING_COLOUR_CODE> 
<0WNER_ID>1</0WNER_ID> 
<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</MAT> 

</MAT_TBL> 

<ORG_TBL> 

<ORG> 

<ORG_ID>2805000000</ORG_ID> 

<CAT_CODE>UN</CAT_CODE> 

<  N I C  KN  AME_N  AME  ><  /  N I C  KN  AME_N  AME  > 
<0WNER_ID>1</0WNER_ID> 
<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</ORG> 

<ORG> 

<ORG_ID>2806000000</ORG_ID> 

<CAT_CODE>UN</CAT_CODE> 

<N  I  CKNAME_NAME  ><  /N I  CKNAME_NAME  > 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</ORG> 

<ORG> 

<ORG_ID>2807000000</ORG_ID> 

<CAT_CODE>UN</CAT_CODE> 

<  N I C  KN  AME_N  AME  ><  /  N I C  KN  AME_N  AME  > 
<0WNER_ID>1</0WNER_ID> 

<UPDATE  SEQNR>1</UPDATE  SEQNR> 
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</ORG> 

<ORG> 

<ORG_ID>2808000000</ORG_ID> 

<CAT_CODE>UN</CAT_CODE> 

<N  I  CKNAME_NAME  ><  /N I  CKNAME_NAME  > 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</ORG> 

<ORG> 

<ORG_ID>2810000000</ORG_ID> 

<CAT_CODE>UN</CAT_CODE> 

<NICKNAME_NAME>TF  TTCP  Blue</NICKNAME_NAME> 
<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</ORG> 

</ORG_TBL> 

<UNIT_TBL> 

<UNIT> 

<UNIT_ID>2805000000</UNIT_ID> 

<  FORMAL_ABBRD_NAME  >FFH2  < / FORMAL_ABBRD_NAME  > 
<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</UNIT> 

<UNIT> 

<UNIT_ID>2806000000</UNIT_ID> 

< FORMAL_ABBRD_NAME >Shee an< / FORMAL_ABBRD_NAME > 
<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</UNIT> 

<UNIT> 

<UNIT_ID>2807000000</UNIT_ID> 

< FORMAL_ABBRD_NAME >UAV< / FORMAL_ABBRD_NAME > 
<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</UNIT> 

<UNIT> 

<UNIT_ID>2808000000</UNIT_ID> 

< FORMAL_ABBRD_NAME >FFH 1< / FORMAL_ABBRD_NAME > 
<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</UNIT> 

<UNIT> 

<UNIT_ID>2810000000</UNIT_ID> 

<FORMAL_ABBRD_NAME>CTFC  TTCP  Blue</FORMAL_ABBRD_NAME> 
<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</UNIT> 

</UNIT_TBL> 

<ORG_MAT_ASSOC_TBL> 

<ORG_MAT_ASSOC> 

<SUB J_ORG_I D>2805000000</ SUB J_ORG_I D> 

<OBJ  MAT  ID>2800000000</OBJ  MAT  ID> 
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<0RG_MAT_ASS0C_IX>1</0RG_MAT_ASS0C_IX> 

<CAT_CODE>CONTRL</CAT_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</ORG_MAT_ASSOC> 

<ORG_MAT_ASSOC> 

<SUBJ_ORG_ID>2806000000</SUBJ_ORG_ID> 
<0B J_MAT_I D>28010000  0  0< /OB J_MAT_I D> 
<ORG_MAT_ASSOC_IX>l</ORG_MAT_ASSOC_IX> 
<CAT_CODE>CONTRL</CAT_CODE> 
<OWNER_ID>l</OWNER_ID> 
<UPDATE_SEQNR>1</UPDATE_SEQNR> 
</ORG_MAT_ASSOC> 

<ORG_MAT_ASSOC> 

<SUB J_ORG_I D>28070000  0  0< / SUB J_ORG_I D> 
<OB J_MAT_I D>2 8 0 2 0 0 0 0 0 0< /OB J_MAT_I D> 
<ORG_MAT_ASSOC_IX>l</ORG_MAT_ASSOC_IX> 
<CAT_CODE>CONTRL</CAT_CODE> 
<OWNER_ID>l</OWNER_ID> 
<UPDATE_SEQNR>1</UPDATE_SEQNR> 
</ORG_MAT_ASSOC> 

<ORG_MAT_ASSOC> 

<SUB J_ORG_I D>2808000000</ SUB J_ORG_I D> 
<OB J_MAT_I D>28030000  0  0< /OB J_MAT_I D> 
<ORG_MAT_ASSOC_IX>l</ORG_MAT_ASSOC_IX> 
<CAT_CODE>CONTRL</CAT_CODE> 
<OWNER_ID>l</OWNER_ID> 
<UPDATE_SEQNR>1</UPDATE_SEQNR> 
</ORG_MAT_ASSOC> 

</ORG_MAT_ASSOC_TBL> 

<OBJ_TYPE_TBL> 

<OBJ_TYPE> 

<OBJ_TYPE_ID>3800000000</OBJ_TYPE_ID> 

<  C AT_CO  DE  >MA< / C AT_CO DE  > 
<DUMMY_IND_CODE>NO</DUMMY_IND_CODE> 
<NAME >T ype 4 5 < / NAME > 

<NAT I ONAL I T Y_C ODE>UK</NATI ONAL I T Y_C 0 DE  > 
<OWNER_ID>l</OWNER_ID> 
<UPDATE_SEQNR>1</UPDATE_SEQNR> 
</OBJ_TYPE> 

<OBJ_TYPE> 

<OBJ_TYPE_ID>3801000000</OBJ_TYPE_ID> 

< C AT_C 0 DE >MA< / C AT_C 0 DE > 

<DUMMY_IND_CODE>NO</DUMMY_IND_CODE> 

<NAME>Collins</NAME> 

<NAT I ONAL I T Y_C ODE>AS</NATI ONAL I T Y_C 0 DE  > 
<OWNER_ID>l</OWNER_ID> 
<UPDATE_SEQNR>1</UPDATE_SEQNR> 
</OBJ_TYPE> 

<OBJ_TYPE> 

<OBJ_TYPE_ID>3802000000</OBJ_TYPE_ID> 

< C AT_C 0 DE >MA< / C AT_C 0 DE > 

<DUMMY  IND  CODE>NO</DUMMY  IND  CODE> 
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<NAME>PredatorNZ</NAME> 

<NATIONALITY_CODE>NZ</NATIONALITY_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_TYPE> 

<OBJ_TYPE> 

<OBJ_TYPE_ID>3803000000</OBJ_TYPE_ID> 

< C AT_C 0 DE >MA< / C AT_C 0 DE > 

<DUMMY_IND_CODE>NO</DUMMY_IND_CODE> 

<NAME>Halifax</NAME> 

<NATIONALIT  Y_CO  DE  >C A< /NATIONALIT Y_CO DE  > 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_TYPE> 

<OBJ_TYPE> 

<OBJ_TYPE_ID>3805000000</OBJ_TYPE_ID> 
<CAT_CODE>OR</CAT_CODE> 
<DUMMY_IND_CODE>NO</DUMMY_IND_CODE> 
<NAME>Naval  Coinbatant</NAME> 

<NAT I ONAL I T Y_CODE>UK< /NAT I ONAL I T Y_CODE> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_TYPE> 

<OBJ_TYPE> 

<OBJ_TYPE_ID>3806000000</OBJ_TYPE_ID> 
<CAT_CODE>OR</CAT_CODE> 
<DUMMY_IND_CODE>NO</DUMMY_IND_CODE> 
<NAME>Naval  Coinbatant</NAME> 

<NAT I ONAL I T Y_C ODE>AS</NATI ONAL I T Y_C 0 DE  > 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_TYPE> 

<OBJ_TYPE> 

<OBJ_TYPE_ID>3807000000</OBJ_TYPE_ID> 

<CAT_CODE>OR</CAT_CODE> 

<DUMMY_IND_CODE>NO</DUMMY_IND_CODE> 

<NAME>Uninanned  Air  Vehicle  Squadron</NAME> 

<NATIONALITY_CODE>NZ</NATIONALITY_CODE> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_TYPE> 

<OBJ_TYPE> 

<OBJ_TYPE_ID>3808000000</OBJ_TYPE_ID> 
<CAT_CODE>OR</CAT_CODE> 
<DUMMY_IND_CODE>NO</DUMMY_IND_CODE> 
<NAME>Naval  Combatant</NAME> 

<NAT I ONAL I T Y_C ODE>CA</NATI ONAL I T Y_C 0 DE  > 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_TYPE> 

<OBJ_TYPE> 

<OBJ_TYPE_ID>3810000000</OBJ_TYPE_ID> 

<CAT_CODE>OR</CAT_CODE> 

<DUMMY  IND  CODE>NO</DUMMY  IND  CODE> 
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<NAME>CTF  Coinmander</NAME> 

<NAT I ONAL I T Y_C ODE>AS</NATI ONAL I T Y_C 0 DE  > 
<OWNER_ID>l</OWNER_ID> 
<UPDATE_SEQNR>1</UPDATE_SEQNR> 
</OBJ_TYPE> 

</OBJ_TYPE_TBL> 

<MAT_TYPE_TBL> 

<MAT_TYPE> 

<MAT_TYPE_ID>3800000000</MAT_TYPE_ID> 

<CAT_CODE>EQ</CAT_CODE> 

<RPTBL_ITEM_TXT></RPTBL_ITEM_TXT> 

<STOCK_NO_TXT></STOCK_NO_TXT> 

<SUPPLY_CLASS_CODE></SUPPLY_CLASS_CODE> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</MAT_TYPE> 

<MAT_TYPE> 

<MAT_T YPE_I D>38010000  0  0< /MAT_T YPE_I D> 
<CAT_CODE>EQ</CAT_CODE> 
<RPTBL_ITEM_TXT></RPTBL_ITEM_TXT> 
<STOCK_NO_TXT></STOCK_NO_TXT> 
<SUPPLY_CLASS_CODE></SUPPLY_CLASS_CODE> 
<OWNER_ID>l</OWNER_ID> 
<UPDATE_SEQNR>1</UPDATE_SEQNR> 
</MAT_TYPE> 

<MAT_TYPE> 

<MAT_T YPE_I D>38020000  0  0< /MAT_T YPE_I D> 
<CAT_CODE>EQ</CAT_CODE> 
<RPTBL_ITEM_TXT></RPTBL_ITEM_TXT> 
<STOCK_NO_TXT></STOCK_NO_TXT> 
<SUPPLY_CLASS_CODE></SUPPLY_CLASS_CODE> 
<OWNER_ID>l</OWNER_ID> 
<UPDATE_SEQNR>1</UPDATE_SEQNR> 
</MAT_TYPE> 

<MAT_TYPE> 

<MAT_T YPE_I D>38030000  0  0< /MAT_T YPE_I D> 
<CAT_CODE>EQ</CAT_CODE> 
<RPTBL_ITEM_TXT></RPTBL_ITEM_TXT> 
<STOCK_NO_TXT></STOCK_NO_TXT> 
<SUPPLY_CLASS_CODE></SUPPLY_CLASS_CODE> 
<OWNER_ID>l</OWNER_ID> 
<UPDATE_SEQNR>1</UPDATE_SEQNR> 
</MAT_TYPE> 

</MAT_TYPE_TBL> 

<EQPT_TYPE_TBL> 

<EQPT_TYPE> 

<EQPT_TYPE_ID>3800000000</EQPT_TYPE_ID> 
<  C AT_CO  DE  > VE  SSEL</CAT_CODE> 
<LOADED_WT_QTY></LOADED_WT_QTY> 
<UNLOADED_WT_QTY>0</UNLOADED_WT_QTY> 
<MAX_HEIGHT_DIM></MAX_HEIGHT_DIM> 

<MAX  LENGTH  DIMX/MAX  LENGTH  DIM> 
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<MAX_WIDTH_DIM></MAX_WIDTH_DIM> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</EQPT_TYPE> 

<EQPT_TYPE> 

<EQPT_TYPE_ID>3801000000</EQPT_TYPE_ID> 

<CAT_CODE>VESSEL</CAT_CODE> 

<LOADED_WT_QTY></LOADED_WT_QTY> 

<UNLOADED_WT_QTY>0</UNLOADED_WT_QTY> 

<MAX_HE I GHT_DIM>< /MAX_HE I GHT_DIM> 

<MAX_LENGTH_DIM></MAX_LENGTH_DIM> 

<MAX_WIDTH_DIM></MAX_WIDTH_DIM> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</EQPT_TYPE> 

<EQPT_TYPE> 

<EQPT_TYPE_ID>3802000000</EQPT_TYPE_ID> 

<CAT_CODE>AIRCFT</CAT_CODE> 

<LOADED_WT_QTY></LOADED_WT_QTY> 

<UNLOADED_WT_QTY>0</UNLOADED_WT_QTY> 

<MAX_HE I GHT_DIM>< /MAX_HE I GHT_DIM> 
<MAX_LENGTH_DIM>< /MAX_LENGTH_DIM> 
<MAX_WIDTH_DIM></MAX_WIDTH_DIM> 
<0WNER_ID>1</0WNER_ID> 
<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</EQPT_TYPE> 

<EQPT_TYPE> 

<EQPT_TYPE_ID>3803000000</EQPT_TYPE_ID> 

<CAT_CODE>VESSEL</CAT_CODE> 

<LOADED_WT_QTY></LOADED_WT_QTY> 

<UNLOADED_WT_QTY>0</UNLOADED_WT_QTY> 

<MAX_HEIGHT_DIM></MAX_HEIGHT_DIM> 

<MAX_LENGTH_DIM>< /MAX_LENGTH_DIM> 

<MAX_WIDTH_DIM></MAX_WIDTH_DIM> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</EQPT_TYPE> 

</EQPT_TYPE_TBL> 

<VESSEL_TYPE_TBL> 

<VESSEL_TYPE> 

<VESSEL_TYPE_ID>3800000000</VESSEL_TYPE_ID> 

<CAT_CODE>SURFAC</CAT_CODE> 

<SUBCAT_CODE>FRIGAT</SUBCAT_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</VESSEL_TYPE> 

<VESSEL_TYPE> 

<VESSEL_TYPE_ID>3801000000</VESSEL_TYPE_ID> 

<CAT_CODE>SUBSRF</CAT_CODE> 

<SUBCAT_CODE>SUBATT</SUBCAT_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</VESSEL  TYPE> 
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<VESSEL_TYPE> 

<VESSEL_TYPE_ID>3803000000</VESSEL_TYPE_ID> 

<CAT_CODE>SUBSRF</CAT_CODE> 

<SUBCAT_CODE>FRIGAT</SUBCAT_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</VESSEL_TYPE> 

</VESSEL_TYPE_TBL> 

<ACFT_TYPE_TBL> 

<ACFT_TYPE> 

<ACFT_TYPE_ID>3  8  02  0  000  0  0< /ACFT_TYPE_ID> 

<CAT_CODE>FIXWNG</CAT_CODE> 

<SUBCAT_CODE>UAV</SUBCAT_CODE> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</ACFT_TYPE> 

</ACFT_TYPE_TBL> 

<ORG_TYPE_TBL> 

<ORG_TYPE> 

<ORG_TYPE_ID>3805000000</ORG_TYPE_ID> 

<CAT_CODE>GVTORG</CAT_CODE> 

<DESCR_TXT>Naval  Unit</DESCR_TXT> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</ORG_TYPE> 

<ORG_TYPE> 

<ORG_TYPE_ID>3806000000</ORG_TYPE_ID> 

<CAT_CODE>GVTORG</CAT_CODE> 

<DESCR_TXT>Naval  Unit</DESCR_TXT> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</ORG_TYPE> 

<ORG_TYPE> 

<ORG_TYPE_ID>3807000000</ORG_TYPE_ID> 

<CAT_CODE>GVTORG</CAT_CODE> 

<DESCR_TXT>Naval  Unit</DESCR_TXT> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</ORG_TYPE> 

<ORG_TYPE> 

<ORG_TYPE_ID>3808000000</ORG_TYPE_ID> 

<CAT_CODE>GVTORG</CAT_CODE> 

<DESCR_TXT>Naval  Unit</DESCR_TXT> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</ORG_TYPE> 

<ORG_TYPE> 

<ORG_TYPE_ID>3810000000</ORG_TYPE_ID> 

<CAT_CODE>GVTORG</CAT_CODE> 

<DESCR_TXT>Coalition  TF  Coinmander</DESCR_TXT> 
<OWNER_ID>l</OWNER_ID> 

<UPDATE  SEQNR>1</UPDATE  SEQNR> 
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</ORG_TYPE> 

</ORG_TYPE_TBL> 

<GOVT_ORG_TYPE_TBL> 

<GOVT_ORG_TYPE> 

<GOVT_ORG_TYPE_ID>3805000000</GOVT_ORG_TYPE_ID> 

<CAT_CODE>MILORG</CAT_CODE> 

<MAIN_ACTIVITY_CODE>NOS</MAIN_ACTIVITY_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

< / GOVT_ORG_T Y  PE  > 

<GOVT_ORG_TYPE> 

<GOVT_ORG_T YPE_I D>38060000  0  0< /GOVT_ORG_T YPE_I D> 
<CAT_CODE>MILORG</CAT_CODE> 

<MAIN_ACTIVITY_CODE>NOS</MAIN_ACTIVITY_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</GOVT_ORG_TYPE> 

<GOVT_ORG_TYPE> 

<GOVT_ORG_TYPE_ID>3807000000</GOVT_ORG_TYPE_ID> 

<CAT_CODE>MILORG</CAT_CODE> 

<MAIN_ACTIVITY_CODE>NOS</MAIN_ACTIVITY_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

< / GOVT_ORG_T Y  PE  > 

<GOVT_ORG_TYPE> 

<GOVT_ORG_T YPE_I D>38080000  0  0< /GOVT_ORG_T YPE_I D> 
<CAT_CODE>MILORG</CAT_CODE> 

<MAIN_ACTIVITY_CODE>NOS</MAIN_ACTIVITY_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</GOVT_ORG_TYPE> 

<GOVT_ORG_TYPE> 

<GOVT_ORG_T YPE_I D>38100000  0  0< /GOVT_ORG_T YPE_I D> 
<CAT_CODE>MILORG</CAT_CODE> 

<MAIN_ACTIVITY_CODE>NOS</MAIN_ACTIVITY_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</GOVT_ORG_TYPE> 

</GOVT_ORG_TYPE_TBL> 

<MIL_ORG_TYPE_TBL> 

<MIL_ORG_TYPE> 

<MIL_ORG_T YPE_I D>38050000  0  0< /MIL_ORG_T YPE_I D> 

<CAT_CODE>UNIT</CAT_CODE> 

<SERVICE_CODE>NAVY</SERVICE_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</MIL_ORG_TYPE> 

<MIL_ORG_TYPE> 

<MI L_ORG_T YPE_I D>38060000  0  0< /MI L_ORG_T YPE_I D> 

<CAT_CODE>UNIT</CAT_CODE> 

<SERVICE_CODE>NAVY</SERVICE_CODE> 

<OWNER  ID>1</0WNER  ID> 
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<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</MIL_ORG_TYPE> 

<MIL_ORG_TYPE> 

<MIL_ORG_T YPE_I D>38070000  0  0< /MIL_ORG_T YPE_I D> 

<CAT_CODE>UNIT</CAT_CODE> 

<SERVICE_CODE>NAVY</SERVICE_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</MIL_ORG_TYPE> 

<MIL_ORG_TYPE> 

<MIL_ORG_TYPE_ID>3808000000</MIL_ORG_TYPE_ID> 

<CAT_CODE>UNIT</CAT_CODE> 

<SERVICE_CODE>NAVY</SERVICE_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</MIL_ORG_TYPE> 

<MIL_ORG_TYPE> 

<MIL_ORG_T YPE_I D>38100000  0  0< /MIL_ORG_T YPE_I D> 

<CAT_CODE>MILPST</CAT_CODE> 

<SERVICE_CODE>NAVY</SERVICE_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</MIL_ORG_TYPE> 

</MIL_ORG_TYPE_TBL> 

<UNIT_TYPE_TBL> 

<UNIT_TYPE> 

<UNIT_TYPE_ID>3805000000</UNIT_TYPE_ID> 

<CAT_CODE>COMBAT</CAT_CODE> 

<ARM_CAT_CODE>NOS</ARM_CAT_CODE> 

<ARM_SPCLSN_CODE>NAVAL</ARM_SPCLSN_CODE> 

<SIZE_CODE>TSKEL</SIZE_CODE> 

<PRINCIPAL_EQPT_TYPE_ID>3800000000</PRINCIPAL_EQPT_TYPE_ID> 

<SUPPORTED_MIL_ORG_TYPE_ID></SUPPORTED_MIL_ORG_TYPE_ID> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</UNIT_TYPE> 

<UNIT_TYPE> 

<UNIT_TYPE_ID>3806000000</UNIT_TYPE_ID> 

<CAT_CODE>COMBAT</CAT_CODE> 

<ARM_CAT_CODE>NOS</ARM_CAT_CODE> 

<ARM_SPCLSN_CODE>NAVAL</ARM_SPCLSN_CODE> 

<SIZE_CODE>TSKEL</SIZE_CODE> 

<PRINCIPAL_EQPT_TYPE_ID>3801000000</PRINCIPAL_EQPT_TYPE_ID> 

<SUPPORTED_MIL_ORG_TYPE_ID></SUPPORTED_MIL_ORG_TYPE_ID> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</UNIT_TYPE> 

<UNIT_TYPE> 

<UNIT_TYPE_ID>3807000000</UNIT_TYPE_ID> 

<CAT_CODE>COMBAT</CAT_CODE> 

< ARM_C AT_C  ODE>NOS</ ARM_C AT_C 0 DE  > 
<ARM_SPCLSN_CODE>NAVAL</ARM_SPCLSN_CODE> 

<SIZE  CODE>TSKEL</SIZE  CODE> 
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<PRINCIPAL_EQPT_TYPE_ID>3802000000</PRINCIPAL_EQPT_TYPE_ID> 

<SUPPORTED_MIL_ORG_TYPE_ID></SUPPORTED_MIL_ORG_TYPE_ID> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</UNIT_TYPE> 

<UNIT_TYPE> 

<UNIT_TYPE_ID>3808000000</UNIT_TYPE_ID> 

<CAT_CODE>COMBAT</CAT_CODE> 

<ARM_CAT_CODE>NOS</ARM_CAT_CODE> 

<ARM_SPCLSN_CODE>NAVAL</ARM_SPCLSN_CODE> 

<SIZE_CODE>TSKEL</SIZE_CODE> 

<PRINCIPAL_EQPT_TYPE_ID>3803000000</PRINCIPAL_EQPT_TYPE_ID> 

<SUPPORTED_MIL_ORG_TYPE_ID></SUPPORTED_MIL_ORG_TYPE_ID> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</UNIT_TYPE> 

</UNIT_TYPE_TBL> 

<MIL_POST_TYPE_TBL> 

<MIL_POST_TYPE> 

<MIL_POST_TYPE_ID>3810000000</MIL_POST_TYPE_ID> 

<CAT_CODE>AUTCDR</CAT_CODE> 

<RANK_C0DE>0F6</RANK_C0DE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</MIL_POST_TYPE> 

</MIL_POST_TYPE_TBL> 

<RPTD_TBL> 

<RPTD> 

<RPTD_ID>4800000000</RPTD_ID> 

< AC  CURAC  Y_C  0  DE  >  3  < / AC CURAC Y_C 0 DE  > 

<CAT_CODE>REP</CAT_CODE> 

<CNTG_IND_CODE>YES</CNTG_IND_CODE> 

<CREDIBILITY_CODE>RPTFCT</CREDIBILITY_CODE> 

<RELIABILITY_CODE>C</RELIABILITY_CODE> 

<REP_DATE>36517</REP_DATE> 

<REP_TIME>54000</REP_TIME> 

<SOURCE_TYPE_CODE>UNSPEC</SOURCE_TYPE_CODE> 

<TIMING_CAT_CODE>RDABST</TIMING_CAT_CODE> 

<REF_ID>1800000000</REF_ID> 

<RE  P_ORG_I D>2810000000</RE  P_ORG_I D> 
<ENT_CAT_CODE>ACTEFF</ENT_CAT_CODE> 
<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</RPTD> 

</RPTD_TBL> 

<RPTD_ABS_TIMING_TBL> 

<RPTD_ABS_TIMING> 

<RPTD_ABS_TIMING_RPTD_ID>4800000000</RPTD_ABS_TIMING_RPTD_ID> 

<DUR>0</DUR> 
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<EFFCTV_DATE>2452764</EFFCTV_DATE> 

<EFFCTV_TIME>54000</EFFCTV_TIME> 

<EFFCTV_TIME_PRECISION_CODE>SECOND</EFFCTV_TIME_PRECISION_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</RPTD_ABS_TIMING> 

</RPTD_ABS_TIMING_TBL> 

<OBJ_ITEM_TYPE_TBL> 

<OBJ_ITEM_TYPE> 

<OBJ_ITEM_ID>2800000000</OBJ_ITEM_ID> 

<OBJ_TYPE_ID>3800000000</OBJ_TYPE_ID> 

<0BJ_ITEM_TYPE_IX>1</0BJ_ITEM_TYPE_IX> 

<RPTD_ID>4800000000</RPTD_ID> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM_TYPE> 

<OBJ_ITEM_TYPE> 

<OBJ_ITEM_ID>2801000000</OBJ_ITEM_ID> 

<OBJ_TYPE_ID>3801000000</OBJ_TYPE_ID> 

<0BJ_ITEM_TYPE_IX>1</0BJ_ITEM_TYPE_IX> 

<RPTD_ID>4800000000</RPTD_ID> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM_TYPE> 

<OBJ_ITEM_TYPE> 

<OBJ_ITEM_ID>2802000000</OBJ_ITEM_ID> 

<OBJ_TYPE_ID>3802000000</OBJ_TYPE_ID> 

<0BJ_ITEM_TYPE_IX>1</0BJ_ITEM_TYPE_IX> 

<RPTD_ID>4800000000</RPTD_ID> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM_TYPE> 

<OBJ_ITEM_TYPE> 

<OBJ_ITEM_ID>2803000000</OBJ_ITEM_ID> 

<OBJ_TYPE_ID>3803000000</OBJ_TYPE_ID> 

<0BJ_ITEM_TYPE_IX>1</0BJ_ITEM_TYPE_IX> 

<RPTD_ID>4800000000</RPTD_ID> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM_TYPE> 

</OBJ_ITEM_TYPE_TBL> 

<OBJ_ITEM_STAT_TBL> 

<OBJ_ITEM_STAT> 

<OBJ_ITEM_ID>2800000000</OBJ_ITEM_ID> 

<0BJ_ITEM_STAT_IX>1</0BJ_ITEM_STAT_IX> 

< C AT_C 0 DE >MA< / C AT_C 0 DE > 

<HSTLY_CODE>AFR</HSTLY_CODE> 

<BOOBY_TRAP_IND_CODE>NO</BOOBY_TRAP_IND_CODE> 

<RPTD_ID>4800000000</RPTD_ID> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ  ITEM  STAT> 
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<OBJ_ITEM_STAT> 

<OBJ_ITEM_ID>2801000000</OBJ_ITEM_ID> 

<0BJ_ITEM_STAT_IX>1</0BJ_ITEM_STAT_IX> 

< C AT_C 0 DE >MA< / C AT_C 0 DE > 
<HSTLY_CODE>AFR</HSTLY_CODE> 

<BOOBY_TRAP_IND_CODE>NO</BOOBY_TRAP_IND_CODE> 

<RPTD_ID>4800000000</RPTD_ID> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM_STAT> 

<OBJ_ITEM_STAT> 

<OBJ_ITEM_ID>2802000000</OBJ_ITEM_ID> 

<0BJ_ITEM_STAT_IX>1</0BJ_ITEM_STAT_IX> 

< C AT_C 0 DE >MA< / C AT_C 0 DE > 
<HSTLY_CODE>AFR</HSTLY_CODE> 

<BOOBY_TRAP_IND_CODE>NO</BOOBY_TRAP_IND_CODE> 

<RPTD_ID>4800000000</RPTD_ID> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM_STAT> 

<OBJ_ITEM_STAT> 

<OBJ_ITEM_ID>2803000000</OBJ_ITEM_ID> 

<0BJ_ITEM_STAT_IX>1</0BJ_ITEM_STAT_IX> 

< C AT_C 0 DE >MA< / C AT_C 0 DE > 
<HSTLY_CODE>AFR</HSTLY_CODE> 

<BOOBY_TRAP_IND_CODE>NO</BOOBY_TRAP_IND_CODE> 

<RPTD_ID>4800000000</RPTD_ID> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM_STAT> 

</OBJ_ITEM_STAT_TBL> 

<OBJ_ITEM_TBL> 

<OBJ_ITEM> 

<OBJ_ITEM_ID>1801000000</OBJ_ITEM_ID> 

<  C AT_CO  DE  >MA< / C AT_CO DE  > 

<NAME>FFG1</NAME> 

<ALTN_IDENTIFIC_TXT>FFG1</ALTN_IDENTIFIC_TXT> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM> 

<OBJ_ITEM> 

<OBJ_ITEM_ID>1801000001</OBJ_ITEM_ID> 

< C AT_C 0 DE >MA< / C AT_C 0 DE > 

<NAME>FFG2</NAME> 

<ALTN_IDENTIFIC_TXT>FFG2</ALTN_IDENTIFIC_TXT> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM> 

</OBJ_ITEM_TBL> 

<MAT_TBL> 

<MAT> 

<MAT  ID>1801000000</MAT  ID> 
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<SERIAL_N0_ID_TXT>FFG-1</SERIAL_N0_ID_TXT> 

<LOT_IDENTIFIC_TXT></LOT_IDENTIFIC_TXT> 

<BODY_COLOUR_CODE>GREY</BODY_COLOUR_CODE> 

<MARK I NG_C ODE>NOS< /MARK I NG_C 0 DE  > 
<MARKING_COLOUR_CODE>NOS</MARKING_COLOUR_CODE> 
<0WNER_ID>1</0WNER_ID> 
<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</MAT> 

<MAT> 

<MAT_ID>1801000001</MAT_ID> 

<SERIAL_N0_ID_TXT>FFG-2</SERIAL_N0_ID_TXT> 

<LOT_IDENTIFIC_TXT></LOT_IDENTIFIC_TXT> 

<BODY_COLOUR_CODE>GREY</BODY_COLOUR_CODE> 

<MARK I NG_C ODE>NOS</ MARK I NG_C 0 DE  > 
<MARKING_COLOUR_CODE>NOS</MARKING_COLOUR_CODE> 
<0WNER_ID>1</0WNER_ID> 
<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</MAT> 

</MAT_TBL> 

<OBJ_TYPE_TBL> 

<OBJ_TYPE> 

<OBJ_TYPE_ID>1901000000</OBJ_TYPE_ID> 

< C AT_C 0 DE >MA< / C AT_C 0 DE > 

<DUMMY_IND_CODE>NO</DUMMY_IND_CODE> 

<NAME>FRIGATE</NAME> 

<NAT I ONAL I T Y_C ODE>OR</NATI ONAL I T Y_C 0 DE  > 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_TYPE> 

</OBJ_TYPE_TBL> 

<MAT_TYPE_TBL> 

<MAT_TYPE> 

<MAT_T YPE_I D>19010000  0  0< /MAT_T YPE_I D> 

<CAT_CODE>EQ</CAT_CODE> 

<RPTBL_ITEM_TXT></RPTBL_ITEM_TXT> 

<STOCK_NO_TXT></STOCK_NO_TXT> 

<SUPPLY_CLASS_CODE></SUPPLY_CLASS_CODE> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</MAT_TYPE> 

</MAT_TYPE_TBL> 

<EQPT_TYPE_TBL> 

<EQPT_TYPE> 

<EQPT_TYPE_ID>1901000000</EQPT_TYPE_ID> 

<CAT_CODE>VESSEL</CAT_CODE> 

<LOADED_WT_QTY>2500000</LOADED_WT_QTY> 

<UNLOADED_WT_QTY>0</UNLOADED_WT_QTY> 

<MAX_HEIGHT_DIM>45</MAX_HEIGHT_DIM> 

<MAX_LENGTH_DIM>125</MAX_LENGTH_DIM> 

<MAX_WIDTH_DIM>15</MAX_WIDTH_DIM> 

<OWNER  ID>l</OWNER  ID> 
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<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</EQPT_TYPE> 

</EQPT_TYPE_TBL> 

<VESSEL_TYPE_TBL> 

<VESSEL_TYPE> 

<VESSEL_TYPE_ID>1901000000</VESSEL_TYPE_ID> 

<CAT_CODE>SURFAC</CAT_CODE> 

<SUBCAT_CODE>FRIGAT</SUBCAT_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</VESSEL_TYPE> 

</VESSEL_TYPE_TBL> 

<OBJ_ITEM_TYPE_TBL> 

<OBJ_ITEM_TYPE> 

<OBJ_ITEM_ID>1801000000</OBJ_ITEM_ID> 

<OBJ_TYPE_ID>1901000000</OBJ_TYPE_ID> 

<0BJ_ITEM_TYPE_IX>1</0BJ_ITEM_TYPE_IX> 

<RPTD_ID>4800000000</RPTD_ID> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM_TYPE> 

<OBJ_ITEM_TYPE> 

<OBJ_ITEM_ID>1801000001</OBJ_ITEM_ID> 

<OBJ_TYPE_ID>1901000000</OBJ_TYPE_ID> 

<0BJ_ITEM_TYPE_IX>1</0BJ_ITEM_TYPE_IX> 

<RPTD_ID>4800000000</RPTD_ID> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM_TYPE> 

</OBJ_ITEM_TYPE_TBL> 

<OBJ_ITEM_STAT_TBL> 

<OBJ_ITEM_STAT> 

<OBJ_ITEM_ID>1801000000</OBJ_ITEM_ID> 

<0BJ_ITEM_STAT_IX>1</0BJ_ITEM_STAT_IX> 

< C AT_C 0 DE >MA< / C AT_C 0 DE > 
<HSTLY_CODE>HO</HSTLY_CODE> 

<BOOBY_TRAP_IND_CODE>NO</BOOBY_TRAP_IND_CODE> 

<RPTD_ID>4800000000</RPTD_ID> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM_STAT> 

<OBJ_ITEM_STAT> 

<OBJ_ITEM_ID>1801000001</OBJ_ITEM_ID> 

<0BJ_ITEM_STAT_IX>1</0BJ_ITEM_STAT_IX> 

< C AT_C 0 DE >MA< / C AT_C 0 DE > 
<HSTLY_CODE>HO</HSTLY_CODE> 

<BOOBY_TRAP_IND_CODE>NO</BOOBY_TRAP_IND_CODE> 

<RPTD_ID>4800000000</RPTD_ID> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ  ITEM  STAT> 
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</OBJ_ITEM_STAT_TBL> 

<! —  Start  Neutral  Description  --> 

<OBJ_TYPE_TBL> 

<OBJ_TYPE> 

<OBJ_TYPE_ID>1901010000</OBJ_TYPE_ID> 

<CAT_CODE>MA</CAT_CODE> 

<DUMMY_IND_CODE>NO</DUMMY_IND_CODE> 

<NAME>Fishing  Vessel</NAME> 

<NATIONALITY_CODE>NZ</NATIONALITY_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_TYPE> 

<OBJ_TYPE> 

<0BJ_TYPE_ID>1 90102 0000</OBJ_TYPE_ID> 

<  C AT_C0  DE  >MA< / C AT_CO DE  > 
<DUMMY_IND_CODE>NO</DUMMY_IND_CODE> 

<NAME>Merchant</NAME> 

<NATIONALITY_CODE>NZ</NATIONALITY_CODE> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_TYPE> 

</OBJ_TYPE_TBL> 

<MAT_TYPE_TBL> 

<MAT_TYPE> 

<MAT_TYPE_ID>1901010000</MAT_TYPE_ID> 

<CAT_CODE>EQ</CAT_CODE> 

<RPTBL_ITEM_TXT></RPTBL_ITEM_TXT> 

<STOCK_NO_TXT></STOCK_NO_TXT> 

<SUPPLY_CLASS_CODE></SUPPLY_CLASS_CODE> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</MAT_TYPE> 

<MAT_TYPE> 

<MAT_TYPE_ID>1901020000</MAT_TYPE_ID> 

<CAT_CODE>EQ</CAT_CODE> 

<RPTBL_ITEM_TXT></RPTBL_ITEM_TXT> 

<STOCK_NO_TXT></STOCK_NO_TXT> 

<SUPPLY_CLASS_CODE></SUPPLY_CLASS_CODE> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</MAT_TYPE> 

</MAT_TYPE_TBL> 

<EQPT_TYPE_TBL> 

<EQPT_TYPE> 

<EQPT_TYPE_ID>1901010000</EQPT_TYPE_ID> 

<CAT_CODE>VESSEL</CAT_CODE> 

<LOADED_WT_QTY></LOADED_WT_QTY> 

<UNLOADED_WT_QTY></UNLOADED_WT_QTY> 

<MAX_HE I GHT_DIM>< /MAX_HE I GHT_DIM> 

<MAX_LENGTH_DIM>< /MAX_LENGTH_DIM> 
<MAX_WIDTH_DIM></MAX_WIDTH_DIM> 

<OWNER  ID>l</OWNER  ID> 
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<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</EQPT_TYPE> 

<EQPT_TYPE> 

<EQPT_TYPE_ID>1 90102 0000</EQPT_TYPE_ID> 

<  C AT_CO  DE  > VE  SSEL</CAT_CODE> 
<LOADED_WT_QTY></LOADED_WT_QTY> 
<UNLOADED_WT_QTY></UNLOADED_WT_QTY> 
<MAX_HEIGHT_DIM></MAX_HEIGHT_DIM> 

<MAX_LENGTH_DIM>< /MAX_LENGTH_DIM> 
<MAX_WIDTH_DIM></MAX_WIDTH_DIM> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</EQPT_TYPE> 

</EQPT_TYPE_TBL> 

<VESSEL_TYPE_TBL> 

<VESSEL_TYPE> 

<VESSEL_TYPE_ID>1901010000</VESSEL_TYPE_ID> 

<CAT_CODE>SURFAC</CAT_CODE> 

<SUBCAT_CODE>FISHER</SUBCAT_CODE> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</VESSEL_TYPE> 

<VESSEL_TYPE> 

<VESSEL_TYPE_ID>1901020000</VESSEL_TYPE_ID> 

<CAT_CODE>SURFAC</CAT_CODE> 

<SUBCAT_CODE>MERSHP</SUBCAT_CODE> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</VESSEL_TYPE> 

</VESSEL_TYPE_TBL> 

<! —  End  Neutral  Description  — > 

<CONTXT_TBL> 

<CONTXT> 

<CONTXT_ID>6800000000</CONTXT_ID> 

<NAME>Sonar  Hull  Array</NAME> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</CONTXT> 

<C0NTXT> 

<CONTXT_ID>6800001000</CONTXT_ID> 

<NAME>Sonar  Towed  Array</NAME> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</CONTXT> 

<CONTXT> 

<CONTXT_ID>6800002000</CONTXT_ID> 

<NAME>Sonobuoy</NAME> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</CONTXT> 

<CONTXT> 

<CONTXT_I D> 68000030  0  0< /CONTXT_I D> 

<NAME>RapiIdly  Deployed  Array</NAME> 
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<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</CONTXT> 

<CONTXT> 

<CONTXT_ID>6800004000</CONTXT_ID> 

<NAME>Side  Scan  Sonar</NAME> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</CONTXT> 

<CONTXT> 

<CONTXT_ID>6800005000</CONTXT_ID> 

<NAME>Surf ace  Search  Radar</NAME> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</CONTXT> 

<CONTXT> 

<CONTXT_ID>6800006000</CONTXT_ID> 

<NAME>Air  Search  Radar</NAME> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</CONTXT> 

<CONTXT> 

<CONTXT_ID>6800007000</CONTXT_ID> 

<NAME >Vi s ua 1< / NAME > 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</CONTXT> 

<CONTXT> 

<CONTXT_I D> 68000080  0  0< /CONTXT_I D> 
<NAME>Electronic  Surveillance  Measures</NAME> 
<OWNER_ID>l</OWNER_ID> 
<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</CONTXT> 

<CONTXT> 

<CONTXT_ID>6800009000</CONTXT_ID> 
<NAME>Acoustic  Fusion</NAME> 
<OWNER_ID>l</OWNER_ID> 
<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</CONTXT> 

<CONTXT> 

<CONTXT_ID>6800010000</CONTXT_ID> 
<NAME>Multi-sensor  Fusion</NAME> 
<OWNER_ID>l</OWNER_ID> 
<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</CONTXT> 

<CONTXT> 

<CONTXT_I D> 68000110  0  0< /CONTXT_I D> 

<NAME>Target  Motion  Analysis</NAME> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</C0NTXT> 

</CONTXT_TBL> 

</GH5Coinplete> 
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Annex  2:  Solution  Report  Load  on  Discovered 
Radar  Contact 


<?xinl  version=  '  1 . 0  '  ?> 

<GH5Coinplete  xmlns : dt="urn : schemas-microsoft-com: datatypes"> 

<RPTD_TBL> 

<RPTD> 

<RPTD_ID>-2147467264</RPTD_ID> 

<ACCURACY_C0DE>3</ACCURACY_C0DE> 

<CAT_CODE>REP</CAT_CODE> 

<CNTG_IND_CODE>YES</CNTG_IND_CODE> 

<CREDIBILITY_CODE>RPTFCT</CREDIBILITY_CODE> 

<RELIABILITY_CODE>C</RELIABILITY_CODE> 

<REP_DATE>00037579</REP_DATE> 

<REP_TIME>062214</REP_TIME> 

<SOURCE_TYPE_CODE>VARI</SOURCE_TYPE_CODE> 

<TIMING_CAT_CODE>RDABST</TIMING_CAT_CODE> 

<REF_ID>1800000000</REF_ID> 

<RE  P_ORG_I D>2805000000</RE  P_ORG_I D> 
<ENT_CAT_CODE>ACTEFF</ENT_CAT_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</RPTD> 

</RPTD_TBL> 

<RPTD_ABS_TIMING_TBL> 

<RPTD_ABS_TIMING> 

<RPTD_ABS_TIMING_RPTD_ID>- 

2147467264</RPTD_ABS_TIMING_RPTD_ID> 

<DUR>0</DUR> 

<EFFCTV_DATE>00037579</EFFGTV_DATE> 

<EFFCTV_TIME>062209</EFFCTV_TIME> 

<EFFGTV_TIME_PRECISION_CODE>SEGOND</EFFGTV_TIME_PRECISION_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</RPTD_ABS_TIMING> 

</RPTD_ABS_TIMING_TBL> 

<LOC_TBL> 

<LOC> 

<LOC_ID>-2147467263</LOC_ID> 

<CAT_CODE>PT</CAT_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</LOG> 

</LOC  TBL> 
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<POINT_TBL> 

<POINT> 

<POINT_ID>-2147467263</POINT_ID> 

<  C AT_CO  DE  > AB  S</CAT_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</POINT> 

</POINT_TBL> 

<VER_DIST_TBL> 

<VER_DIST> 

<VER_DIST_ID>-2147467263</VER_DIST_ID> 

<CAT_CODE>LOCSUR</CAT_CODE> 

<DIM>0</DIM> 

<PRECISION_CODE>10M</PRECISION_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</VER_DIST> 

</VER_DIST_TBL> 

<ABS_POINT_TBL> 

<ABS_POINT> 

<ABS_POINT_ID>-2147467263</ABS_POINT_ID> 

<LAT_COORD>34 . 2</LAT_C00RD> 

<LONG_COORD>93 . 2</L0NG_C00RD> 

< ANGUL AR_PRE  C I S I ON_C ODE>SECOND</ ANGUL AR_PRE C I S I ON_C 0 DE > 

<ABS_POINT_VER_DIST_ID>-2147467263</ABS_POINT_VER_DIST_ID> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</ABS_POINT> 

</ABS_POINT_TBL> 

<OBJ_ITEM_LOC_TBL> 

<OBJ_ITEM_LOC> 

<LOC_ID>-2147467263</LOC_ID> 

<OBJ_ITEM_ID>2800000000</OBJ_ITEM_ID> 

<0BJ_ITEM_L0C_IX>1</0BJ_ITEM_L0C_IX> 

<ACCURAC Y_QT Y>< / ACCURAC Y_QT Y> 

<BEARING_ANGLE>271 . 5</BEARING_ANGLE> 

<SPEED_RATE>5 . 6</SPEED_RATE> 

<GEOMETRY_CFEAT_TYPE_ID></GEOMETRY_CFEAT_TYPE_ID> 

<RPTD_ID>-2147467264</RPTD_ID> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM_LOC> 

</OBJ_ITEM_LOC_TBL> 

<RPTD_TBL> 

<RPTD> 

<RPTD_ID>-2147467262</RPTD_ID> 

< AC  CURAC  Y_C  0  DE  >  3  < /ACCURAC Y_C 0 DE  > 

<CAT_CODE>REP</CAT_CODE> 

<CNTG  IND  CODE>YES</CNTG  IND  CODE> 
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<CREDIBILITY_CODE>RPTFCT</CREDIBILITY_CODE> 

<RELIABILITY_CODE>C</RELIABILITY_CODE> 

<REP_DATE>00037579</REP_DATE> 

<REP_TIME>062214</REP_TIME> 

<SOURCE_TYPE_CODE>CONTAC</SOURCE_TYPE_CODE> 

<TIMING_CAT_CODE>RDABST</TIMING_CAT_CODE> 

<REF_ID>1800000000</REF_ID> 

<RE  P_ORG_I D>2805000000</RE  P_ORG_I D> 
<ENT_CAT_CODE>ACTEFF</ENT_CAT_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</RPTD> 

</RPTD_TBL> 

<RPTD_ABS_TIMING_TBL> 

<RPTD_ABS_TIMING> 

<RPTD_ABS_TIMING_RPTD_ID>- 

2147467262</RPTD_ABS_TIMING_RPTD_ID> 

<DUR>0</DUR> 

<EFFCTV_DATE>00037579</EFFCTV_DATE> 

<EFFCTV_TIME>062209</EFFCTV_TIME> 

<EFFCTV_TIME_PRECISION_CODE>SECOND</EFFCTV_TIME_PRECISION_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</RPTD_ABS_TIMING> 

</RPTD_ABS_TIMING_TBL> 

<OBJ_ITEM_TBL> 

<OBJ_ITEM> 

<OBJ_ITEM_ID>-2147467259</OBJ_ITEM_ID> 

< C AT_C 0 DE >MA< / C AT_C 0 DE > 

<NAME>TeKaha_Radar_01_Merchant6_2 : 2</NAME> 

<ALTN_IDENTIFIC_TXT>vRealWorldContact_8</ALTN_IDENTIFIC_TXT> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM> 

</OBJ_ITEM_TBL> 

<MAT_TBL> 

<MAT> 

<MAT_I D>-2147467259< /MAT_I D> 
<SERIAL_NO_ID_TXT></SERIAL_NO_ID_TXT> 
<LOT_IDENTIFIC_TXT></LOT_IDENTIFIC_TXT> 
<BODY_COLOUR_CODE>NOS</BODY_COLOUR_CODE> 

<MARK I NG_C ODE>NOS</ MARK I NG_C 0 DE  > 

<MARKING_COLOUR_CODE>NOS</MARKING_COLOUR_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</MAT> 

</MAT_TBL> 

<OBJ  ITEM  TYPE  TBL> 
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<OBJ_ITEM_TYPE> 

<OBJ_ITEM_ID>-2147467259</OBJ_ITEM_ID> 
<0BJ_TYPE_ID>1 90102 0000</OBJ_TYPE_ID> 
<OBJ_ITEM_TYPE_IX>l</OBJ_ITEM_TYPE_IX> 
<RPTD_ID>-2147467262</RPTD_ID> 
<OWNER_ID>l</OWNER_ID> 
<UPDATE_SEQNR>1</UPDATE_SEQNR> 
</OBJ_ITEM_TYPE> 

</OBJ_ITEM_TYPE_TBL> 

<OBJ_ITEM_STAT_TBL> 

<OBJ_ITEM_STAT> 

<OBJ_ITEM_ID>-2147467259</OBJ_ITEM_ID> 

<OBJ_ITEM_STAT_IX>l</OBJ_ITEM_STAT_IX> 

<  C AT_CO  DE  >MA< / C AT_CO DE  > 
<HSTLY_CODE>AFR</HSTLY_CODE> 

<BOOBY_TRAP_IND_CODE>NO</BOOBY_TRAP_IND_CODE> 

<RPTD_ID>-2147467262</RPTD_ID> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM_STAT> 

</OBJ_ITEM_STAT_TBL> 

<LOC_TBL> 

<LOC> 

<LOC_ID>-2147467260</LOC_ID> 

<CAT_CODE>PT</CAT_CODE> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</LOC> 

</LOC_TBL> 

<POINT_TBL> 

<POINT> 

<POINT_ID>-2147467260</POINT_ID> 

<  C AT_CO  DE  > AB  S</CAT_CODE> 
<OWNER_ID>l</OWNER_ID> 
<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</POINT> 

</POINT_TBL> 

<VER_DIST_TBL> 

<VER_DIST> 

<VER_DIST_ID>-2147467260</VER_DIST_ID> 

<CAT_CODE>LOCSUR</CAT_CODE> 

<DIM>0</DIM> 

<PRECISION_CODE>10M</PRECISION_CODE> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</VER_DIST> 

</VER_DIST_TBL> 

<ABS_POINT_TBL> 

<ABS  POINT> 
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<ABS_POINT_ID>-2147467260</ABS_POINT_ID> 

<LAT_COORD>35 . 5</LAT_C00RD> 

<LONG_COORD>95 . 5</L0NG_C00RD> 

<ANGULAR_PRECISION_CODE>SECOND</ANGULAR_PRECISION_CODE> 

<ABS_POINT_VER_DIST_ID>-2147467260</ABS_POINT_VER_DIST_ID> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</ABS_POINT> 

</ABS_POINT_TBL> 

<CONTXT_RPTD_ASSOC_TBL> 

<CONTXT_RPTD_ASSOC> 

<CONTXT_I D> 68000050  0  0< /CONTXT_I D> 
<RPTD_ID>-2147467262</RPTD_ID> 

<CONTXT_RPTD_ASSOC_IX>l</CONTXT_RPTD_ASSOC_IX> 

<CAT_CODE>ISDFT</CAT_CODE> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</CONTXT_RPTD_ASSOC> 

</CONTXT_RPTD_ASSOC_TBL> 

<LOC_TBL> 

<LOC> 

<LOC_ID>-2147467258</LOC_ID> 

<CAT_CODE>PT</CAT_CODE> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</LOC> 

<LOC> 

<LOC_ID>-2147467257</LOC_ID> 

<CAT_CODE>PT</CAT_CODE> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</LOC> 

<LOC> 

<LOC_ID>-2147467256</LOC_ID> 

<CAT_CODE>SURFAC</CAT_CODE> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</LOC> 

</LOC_TBL> 

<POINT_TBL> 

<POINT> 

<POINT_ID>-2147467258</POINT_ID> 

<  C AT_CO  DE  > AB  S</CAT_CODE> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</POINT> 

<POINT> 

<POINT_ID>-2147467257</POINT_ID> 

<CAT_CODE>ABS</CAT_CODE> 

<OWNER_ID>l</OWNER_ID> 

<UPDATE  SEQNR>1</UPDATE  SEQNR> 
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</POINT> 

</POINT_TBL> 

<VER_DIST_TBL> 

<VER_DIST> 

<VER_DIST_ID>-2147467258</VER_DIST_ID> 

<CAT_CODE>LOCSUR</CAT_CODE> 

<DIM>0</DIM> 

<PRECISION_CODE>10M</PRECISION_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</VER_DIST> 

<VER_DIST> 

<VER_DIST_ID>-2147467257</VER_DIST_ID> 

<CAT_CODE>LOCSUR</CAT_CODE> 

<DIM>0</DIM> 

<PRECISION_CODE>10M</PRECISION_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</VER_DIST> 

</VER_DIST_TBL> 

<ABS_POINT_TBL> 

<ABS_POINT> 

<ABS_POINT_ID>-2147467258</ABS_POINT_ID> 

<LAT_COORD>35 . 6</LAT_C00RD> 

<LONG_COORD>95 . 6</L0NG_C00RD> 

< ANGUL AR_PRE  C I S I ON_C ODE>SECOND</ ANGUL AR_PRE C I S I ON_C 0 DE > 

<ABS_POINT_VER_DIST_ID>-2147467258</ABS_POINT_VER_DIST_ID> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</ABS_POINT> 

<ABS_POINT> 

<ABS_POINT_I D>-2147467257< / ABS_POINT_I D> 

<LAT_COORD>35 . 4</LAT_C00RD> 

<LONG_COORD>95 . 4</L0NG_C00RD> 

< ANGUL AR_PRE  C I S I ON_C ODE>SECOND</ ANGUL AR_PRE C I S I ON_C 0 DE > 

<ABS_POINT_VER_DIST_ID>-2147467257</ABS_POINT_VER_DIST_ID> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</ABS_POINT> 

</ABS_POINT_TBL> 

<SURFACE_TBL> 

<SURFACE> 

<SURFACE_I D>-2 1 4  7  4  6725  6</SURFACE_I D> 
<CAT_CODE>ELLPSE</CAT_CODE> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</SURFACE> 

</SURFACE_TBL> 

<ELPS_TBL> 

<ELPS> 
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<ELPS_ID>-2147467256</ELPS_ID> 

<ELPS_CENTRE_POINT_ID>-2147467260</ELPS_CENTRE_POINT_ID> 
<ELPS_FIRST_CNJG_DIAM_POINT_ID>- 
2147467258</ELPS_FIRST_CNJG_DIAM_POINT_ID> 
<ELPS_SCND_CNJG_DIAM_POINT_ID>- 
21474 67257</ELPS_SCND_CNJG_DIAM_POINT_ID> 
<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</ELPS> 

</ELPS_TBL> 

<OBJ_ITEM_LOC_TBL> 

<OBJ_ITEM_LOC> 

<LOC_ID>-2147467256</LOC_ID> 

<OBJ_ITEM_ID>-2147467259</OBJ_ITEM_ID> 

<0BJ_ITEM_L0C_IX>1</0BJ_ITEM_L0C_IX> 

<ACCURAC Y_QT Y>< / ACCURAC Y_QT Y> 

<BEARING_ANGLE>45 . 6</BEARING_ANGLE> 

<SPEED_RATE>12 . 34</SPEED_RATE> 

<GEOMETRY_CFEAT_TYPE_ID></GEOMETRY_CFEAT_TYPE_ID> 

<RPTD_ID>-2147467262</RPTD_ID> 

<0WNER_ID>1</0WNER_ID> 

<UPDATE_SEQNR>1</UPDATE_SEQNR> 

</OBJ_ITEM_LOC> 

</OBJ_ITEM_LOC_TBL> 

</ GH5Coinplete> 
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List  of 

symbols/abbreviations/acronyms/initialisms 


API 

Application  Programming  Interface 

ATCCIS 

Army  Tactical  Command  and  Control  Information  System 

AS 

Australia 

C2IEDM 

Command  and  Control  Information  Exchange  Data  Model 

C2IS 

Command  and  Control  Information  System 

CA 

Canada 

Comms 

Communications 

CTF 

Coalition  Task  Force 

DND 

Department  of  National  Defence 

DRDC 

Defence  R&D  Canada 

DSL 

Data  Services  Layer 

ER 

Entity  -  Relationship 

ESM 

Electronic  Support  Measures 

FFH 

Frigate,  Helicopter 

PEG 

Guided  Missile  Frigate 

GH 

Generic  Hub 

HLA 

High  Level  Architecture 

JDBC 

Java  Database  Connectivity 

LC2IEDM 

Land  Command  and  Control  Information  Exchange  Data  Model 

MAR 

Maritime  Systems  Group 

NBC 

Nuclear-Biological-Chemical 

NEC 

Network  Enabled  Capability 
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NCW 

NUW 

NUWC 

NZ 

OCXS 

RTI 

SAX 

SQL 

TF 

TP-1 

TTCP 

UAV 

UK 

US 

VBE 

VBE-B 

XML 

XSLT 


Net  Centric  Warfare 
Networked  Underwater  Warfare 
Naval  Undersea  Warfare  Center 
New  Zealand 

Operational  Context  Exchange  Service 
Runtime  Infrastructure 
Simple  API  for  XML 
Structured  Query  Language 
Task  Force 

Technical  Panel  -  One 

The  Technical  Cooperation  Program 

Unmanned  Aerial  Vehicle 

United  Kingdom 

United  States 

Virtual  Battle  Experiment 

Virtual  Battle  Experiment  -  Bravo 

extensible  Markup  Language 

extensible  Stylesheet  Language  Transformations 
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